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

[Fangrui Song]

Hi Florian,

Thanks for your comments.

On 2020-04-11, Florian Weimer wrote:
>* Fangrui Song via Libc-alpha:
>
>> On 2020-04-08, Florian Weimer wrote:
>>>* Fangrui Song via Libc-alpha:
>>>
>>>> When using lld as the linker, configure prints a confusing message.
>>>>
>>>> *** These critical programs are missing or too old: GNU ld
>>>>
>>>> lld>=8 can build glibc with very few patches. lld may be built with a
>>>> custom version information (e.g. git commit ID), so a version check is not
>>>> useful at all.
>>>
>>>If additional patches are still required, we should not change the
>>>configure check at this time.
>>>
>>>To be clear, this is an objection from me.  Sorry.
>>>
>>>Thanks,
>>>Florian
>>
>> Hi Florian,
>>
>> Can you help with https://sourceware.org/pipermail/libc-alpha/2020-March/111910.html ?
>
>I'm not sure what the problem discussed on this thread is (besides an
>lld incompatibility).

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.

--start-lib all-members-exceptmalloc.o --end-lib is better but GNU ld
does not support the feature
https://sourceware.org/bugzilla/show_bug.cgi?id=24600


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
       |        ^~~~
../sysdeps/unix/sysv/linux/libc_fatal.c: In function ‘writev_for_fatal’:
../sysdeps/unix/sysv/linux/libc_fatal.c:27:11: warning: implicit declaration of function ‘INTERNAL_SYSCALL_CALL’ [-Wimplicit-function-declaration]
    27 |     cnt = INTERNAL_SYSCALL_CALL (writev, fd, iov, niov);

>> 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)