[PATCH] install: Delete scripts/output-format.sed and support lld
Fangrui Song
maskray@google.com
Sun May 3 20:53:40 GMT 2020
On 2020-05-03, Florian Weimer wrote:
>* Fangrui Song via Libc-alpha:
>
>> GNU ld and gold can skip a script with incompatible OUTPUT_FORMAT and
>> find the next script in the search path. So libc.so linked with lld
>> cannot be skipped automatically. However, this is considered a minor
>> functionality loss by lld maintainers.
>
>That completely depends on how typical installations set up their
>linker search paths. Figuring that out is likely more work than
>providing the correct OUTPUT_FORMAT information in the linker script,
>so I'm not sure if the patch goes in the right direction.
For typical installations, OUTPUT_FORMAT is not useful.
Even in multilib installations, OUTPUT_FORMAT is not useful unless, for
example, /usr/lib is in both -m32 and -m64's library search paths (this
is likely a misconfiguration).
`OUTPUT_FORMAT(elf64-x86-64)` can provide some protection for GNU ld and
gold.
>But as I said, it's probably better to find an alternative way to
>generate the right OUTPUT_FORMAT directive for the linker script.
We (LLD developers) consider OUTPUT_FORMAT with GNU ld/gold semantic has
very little value. See https://bugs.llvm.org/show_bug.cgi?id=37432 and
https://bugs.llvm.org/show_bug.cgi?id=43740
>In any case, the choice of linker for building glibc should result in
>as little semantic difference in the produced artifacts, to avoid
>inflating the compatibility matrix. If OUTPUT_FORMAT is indeed
>unnecessary (based on the evaluation I mentioned), it should be
>removed unconditionally.
If there is concern about the aforementioned value, then we probably
should not drop OUTPUT_FORMAT for now for GNU ld/gold. If people think
we can remove OUTPUT_FORMAT as well, I will be happy to create a
follow-up patch.
More information about the Libc-alpha
mailing list