Summary: | [meta] Build glibc with LLD | ||
---|---|---|---|
Product: | glibc | Reporter: | Fangrui Song <i> |
Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | drepper.fsp, hjl.tools |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2020-09-01 00:00:00 | |
Bug Depends on: | 26559 | ||
Bug Blocks: |
Description
Fangrui Song
2020-08-31 23:19:30 UTC
(In reply to Fangrui Song from comment #0) > Some known issues: > > * elf/librtld.map.o uses a subtle property of --defsym: > https://sourceware.org/pipermail/libc-alpha/2020-April/112732.html Since --defsym in ldd is incompatible with glibc build, --defsym should be poisoned for glibc build. > * ld.lld --verbose does not print a linker script and ld.lld > --print-output-format is not supported: > https://sourceware.org/pipermail/libc-alpha/2020-April/112733.html > * Neither clang nor LLD may support the semantics of .tls_common > https://sourceware.org/pipermail/libc-alpha/2020-April/112734.html This is used to implement STT_COMMON. Do clang/LLD support STT_COMMON? I think you should make your glibc branch for lld available so that people can give it a try. Before lld can be accepted for glibc build, it must generate the same set of failures in glibc testsuite with binutils 2.35 at least on i686 and x86-64. Fixed by https://sourceware.org/git/?p=glibc.git;a=commit;h=224edada607ebc6aaa1aadaae423128fae7880df ("configure: Allow LD to be LLD 13.0.0 or above [BZ #26558]") Target: 2.35 |