[lld] LLVM successful link depends on static libraries order

[MarkaPola]

CMake 3.31.0 extend the deduplication of static libraries to new environments.

Unfortunately, the version 3.31.0 introduce an unwanted side-effect regarding lld usage which reveal a problem with lld in case of ELF binary format: if static libraries are deduplicated, the success or failure of the build of LLVM depends on the order of the static libraries. For other binary format (COFF, Mach-O) the link is successful regardless the order of static libraries.
Unfortunately, I was unable to reproduce this problem on a simple example.

The full history of this problem can be consulted on the CMake-26447 issue.

FYI, CMake version 3.31.1 will suppress this side effect, but users of lld will potentially be confronted to this bug if static libraries deduplication is active.

[llvmbot]

@llvm/issue-subscribers-lld-elf

Author: Marc Chevrier (MarkaPola)

`CMake` 3.31.0 extend the deduplication of static libraries to new environments.

Unfortunately, the version 3.31.0 introduce an unwanted side-effect regarding lld usage which reveal a problem with lld in case of ELF binary format: if static libraries are deduplicated, the success or failure of the build of LLVM depends on the order of the static libraries. For other binary format (COFF, Mach-O) the link is successful regardless the order of static libraries.
Unfortunately, I was unable to reproduce this problem on a simple example.

The full history of this problem can be consulted on the CMake-26447 issue.

FYI, CMake version 3.31.1 will suppress this side effect, but users of lld will potentially be confronted to this bug if static libraries deduplication is active.

[MaskRay]

Archive semantics are special
https://maskray.me/blog/2021-06-20-symbol-processing#shared-object-overriding-archive

With the limited information I am not sure we can get any conclusion. Do you have a smaller reproduce?

[tambry]

I tried to make a reproducer in November but I didn't understand the internals enough to create one from scratch and reducing from LLVM would've been a tall order so I gave up.

The best reproducer I can do is:

1. Build CMake with this line commented out (i.e. revert CMake's workaround).
2. Revert this change (i.e. the LLVM-side workaround for CMake 3.31.0).
3. Build LLVM with the workaround-reverted CMake:

   custom_cmake/build/bin/cmake ../llvm -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_LINK_LLVM_DYLIB=ON -DLLVM_TARGETS_TO_BUILD="X86" && ninja libclang-cpp.so
   

4. The linking of libclang-cpp.so fails.

build.ninja (regular): build.ninja_good.gz
build.ninja (workaround reverted): build.ninja_bad.gz

The link line of lib/libclang.so.21.0.0git changes quite a bit between full and shared-only deduplication.