gcc's link path does not contain the directory with the system libraries

[bhaible]

When system functions are made available as include files, they should also be made available as libraries. In other words, if a user does not need to add particular -I options on the gcc command line in order to get a header file, he also should not have to add a particular -L option in order to get access to the directory where the library is defined. And vice versa.

<netdb.h> is in the default -I include path, but libnet.so is not in the default -L library path.

I really don't want to add absolute directory names like /boot/beos/system/lib to gnulib's autoconf macros. The alternative is to document that configure should always be invoked with option LDFLAGS="-L/boot/beos/system/lib", but this is lame as well.

I'm not sure whether it's gcc or ld which should be changed.

[bhaible]

screenshot of failed gcc commands

[andreasf]

You shouldn't use libnet.so on Haiku in the first place. :) Or do you face the same issue for libnetwork.so?

[bhaible]

do you face the same issue for libnetwork.so?

Indeed, linking with -lnetwork works fine. But I thought Haiku intented to be backwards compatible with BeOS? On BeOS, there is no libnetwork.so, only libnet.so.

[andreasf]

Backwards compatible at runtime, not necessarily at compile time.

[mmlr]

Source compatibility is only kept where it makes sense. The problem with the networking libraries is that there are R5 (-lnet) and BONE versions and in BONE, the networking functions were additionally spread across different libraries (-lbind and -lsocket) which was always a bit inconvenient. Therefore Haiku has libnetwork that combines all of them (-lnet, -lbind and -lsocket). You will find that all of them are just symlinks to libnetwork under Haiku. The compatible functions are then chosen based on the originally linked to library.

[bhaible]

Thanks for explaining. I'm changing gnulib to try -lnetwork before -lnet.