llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.15k stars 12.03k forks source link

[lld] LLVM successful link depends on static libraries order #116669

Open MarkaPola opened 3 hours ago

MarkaPola commented 3 hours ago

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 commented 2 hours ago

@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](https://gitlab.kitware.com/cmake/cmake/-/issues/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.