[PATCH] configure: Allow LD to be a linker other than GNU ld and gold

[Fangrui Song]

On 2020-04-11, Florian Weimer wrote:
>* Fangrui Song:
>
>> commit 3a0ecccb599a6b1ad4b149dc569c0080e92d057b "ld.so: Do not export free/calloc/malloc/realloc functions [BZ #25486]"
>> makes more use of a subtle --defsym behavior (gold/LLD incompatibility).
>>
>> If my understanding is correct, we can extract the members of
>> libc_pic.a, make a thin archive with all member except malloc.o,
>> then link librtld.map with the thin archive.
>
>I think it's more reliable to list the symbols, not the object,
>because it's the symbols (mainly those defined in dl-minimal.c) that
>need special treatment, not the object file.

OK. --defsym defines a SHN_ABS symbol, not perfectly robust because a
normal definition is relative to the image base.

This subtless does not cause
https://sourceware.org/bugzilla/show_bug.cgi?id=25749 but it will be
nice to drop the reliance on it.

If I add a stub.s to define these symbols, AS it, then place it as the
first input file to shadow libc_pic.a, will such a patch be acceptable?

Similarly,
https://sourceware.org/pipermail/libc-alpha/2020-April/112628.html will be a main showstopper if it cannot be applied.

If either one is not acceptable, then LLD can never link glibc. I'll stop wasting my efforts.

>> With my patches, I am seeing some weird compiler errors (not linker errors...). They are likely build system brittleness somewhere:
>>
>> % ../configure --prefix=/tmp/opt2 --disable-werror
>> % make -j 10
>> ...
>> In file included from localeinfo.h:224,
>>                   from lc-ctype.c:19:
>> lc-ctype.c: In function ‘_nl_postload_ctype’:
>> ../sysdeps/generic/libc-tsd.h:58:43: error: ‘__libc_tsd_CTYPE_B’ undeclared (first use in this function)
>>     58 | #define __libc_tsd_set(TYPE, KEY, VALUE) (__libc_tsd_##KEY = (VALUE))
>>        |                                           ^~~~~~~~~~~
>> lc-ctype.c:67:7: note: in expansion of macro ‘__libc_tsd_set’
>>     67 |       __libc_tsd_set (const uint16_t *, CTYPE_B,
>>
>> ../sysdeps/unix/sysv/linux/libc_fatal.c:22:8: error: unknown type name ‘bool’
>>     22 | static bool
>>        |        ^~~~
>
>That suggests that the include path ordering is not correct and
>include/ctype.h is not included.  I don't remember seeing anything
>like that.

I am fairly certain this is a problem with the build system because I
just add /usr/local/bin/ld as a symlink to the latest lld...
(and deleted it to verify GNU ld builds)

>>>> To be honest, this LD capability check looks very strange to me. I
>>>> believe a good configure time check should check the problem explicitly,
>>>> rather than the version, e.g. if a known version can silently cause a
>>>> bug, then we should reject it. The current version check can just give
>>>> false positives and/or false negatives.  https://ewontfix.com/13/
>>>
>>>The configure checks can be difficult to maintain.  We generally give
>>>wide latitude on the accepted versions.  Earlier ones often really do
>>>not work and produce a broken library.
>>
>> This is based on the fact that some older versions of GNU ld may
>> silently create corrupted glibc.
>>
>> With an incapable older LLD, we just see some linker errors (it
>> generally has stronger error checking from my experience. You can search
>> for the many ld bugs/feature requests I reported/commented on)
>
>We still have the problem that users on a system which uses lld by
>default will encounter these link errors and think that it's there
>fault because we have a configure check that recognizes lld.