libnetwork.so has undefined references to several _-prefixed symbols that ought to be in libnetwork

[grubba]

A long linker command fails with:

/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_res_init'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_inet_net_ntop'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_inet_net_pton'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_res_query'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_inet_cidr_pton'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_dn_expand'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_res_mkquery'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_inet_cidr_ntop'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_herror'
/bin/ld /boot/system/develop/lib/libnetwork.so: undefined reference to `_res_search'

The above symbols do not seem to be provided by anything in /system/lib/lib*.

Running nm on libnetwork.so hints that the problem is likely that the definitions of the above symbols either have been prefixed with an extra _, or one too few:

000000000002ec70 T __dn_expand
0000000000010ea0 T __inet_cidr_ntop
0000000000011650 T __inet_cidr_pton
0000000000011960 T __inet_net_ntop
0000000000012100 T __inet_net_pton
000000000002eec0 T __res_init
000000000002efb0 T __res_mkquery
000000000002f040 T __res_query
000000000002f170 T __res_search
0000000000010ea0 W inet_cidr_ntop
0000000000011650 W inet_cidr_pton
0000000000011960 W inet_net_ntop
0000000000012100 W inet_net_pton
000000000002ea50 W herror

I suspect that a compilation unit in the library has been compiled with the old BSD/pre-ELF convention of prefixing C-symbols with a single _, or that a glue object is missing from the library.

[waddlesplash]

This is strange. I do see the references to those symbols in some of libnetwork.so's source files, but I am pretty sure we build the whole system with --no-undefined, so I don't know how that could have happened. Probably because they are defined as weak symbols? But then we shouldn't see undefined references for them, they should just turn out to be NULL.

[pulkomandy]

Can you share the complete linker command? There is likely a flag that triggers the problem in it, since many things link against libnetwork and don't see this problem.

[grubba]

The issue was made visible by an attempt to link a binary which made use of __attribute__((visibility("protected"))) symbols. The default linker command as generated by the default gcc specs gives the option -shared even when linking an executable. This caused it to fail with:

.../bin/ld: other.o: relocation R_X86_64_PC32 against protected symbol `protected_sym' can not be used when making a shared object

> gcc --dumpspecs
[...]
*link:
%{!static|static-pie:--eh-frame-hdr} %{!m32:-m elf_x86_64_haiku} %{m32:-m elf_i386_haiku}       %{!r:-shared} %{nostart:-e 0} %{shared:-e 0} %{!shared: %{!nostart: -no-undefined}}
[...]

As seen above, the rule %{!r:-shared} will give the option -shared to collect2 except when performing a partial link (ie compiling with -r).

Running the collect2 command without -shared caused it to instead complain about libnetwork.so as in my original report.

I suspect that -no-undefined is inhibited by -shared.

Anyway, I currently avoid my initial issue by using __attribute__((visibility("default"))) for now, and can thus link without using a custom specs file.

[pulkomandy]

-shared is intentionally enabled for all executables in Haiku. This is needed in particular for 'replicants' to work (loading parts of an executable code inside another one's address space).

I don't think there is much testing for building things with -shared disabled.