The issue bisects to commit c1c4cf95 from !9665 (merged).
LLVM is big so it's hard for me to minify and the problematic commit is quite a big change too.
CC @marc.chevrier.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
Related merge requests
2
When these merge requests are accepted, this issue will be closed automatically.
@tambre I have some questions to try to identify the problem:
Is the problem specific to your development branch or the stable release of LLVM has also concerned?
Did-you specify CMAKE_LINKER_TYPE variable or LINKER_TYPE target property?
Can you give-me back the values of CMAKE_<LANG>_COMPILER_LINKER, CMAKE_<LANG>_COMPILER_LINKER_ID and CMAKE_<LANG>_COMPILER_LINKER_FRONTEND_VARIANT defined in file <build-dir>/CMakeFiles/<cmake-version>/CMake<LANG>Compiler.cmake>?
Is the LLVM linker (ld.lld) is standard or do you have a patched one?
Can you try two different builds with the following changes (one per build):
CMAKE_<lang>_LINK_DEPENDS_USE_LINKER with value FALSE
CMAKE_<lang>_LINK_LIBRARIES_PROCESSING with value ORDER=REVERSE;DEDUPLICATION=SHARED
Is the problem specific to your development branch or the stable release of LLVM has also concerned?
I've switched to current CMake master (84c8003e) for further debugging.
Latest stable llvmorg-19.1.3 isn't affected.
Current tip-of-the-tree (33694245cba0e935f516edf9d20c9062692b1289) is affected.
Did-you specify CMAKE_LINKER_TYPE variable or LINKER_TYPE target property?
No. cmake invocation is exactly as shown in the reproduction steps.
I also fully clear the build directory (rm -r * .*) for each test.
Can you give-me back the values of CMAKE_<LANG>_COMPILER_LINKER, CMAKE_<LANG>_COMPILER_LINKER_ID and CMAKE_<LANG>_COMPILER_LINKER_FRONTEND_VARIANT defined in file <build-dir>/CMakeFiles/<cmake-version>/CMake<LANG>Compiler.cmake>?
Is the LLVM linker (ld.lld) is standard or do you have a patched one?
Standard.
Built from the Bloomberg P2996 fork, but they've only modified the Clang frontend to add reflection support. I can easily switch to upstream LLVM but it shouldn't change anything.
CMAKE_<lang>_LINK_DEPENDS_USE_LINKER with value FALSE
The configuration regarding the linker is OK, and the main changes brought by the new linker infrastructure (i.e. linker dependencies support and archive libraries deduplication) seems not the root of the problem.
The problem seems more complex than expected If I understand right:
The stable release of LLVM build correctly with the new CMake linker infrastructure
The development branch of LLVM build correctly with the old CMake linker infrastructure
So the problem occurred only with the conjunction of the latest LLVM sources and new CMake linker infrastructure! For now, I have no clue of the source of the problem... I will analyze your various log files.
@tambre Is it possible for you to try a build of your environment but with the linker from the stable version (i.e. 19.1.3)? This check will enable to exonerate the development version of the linker.
@tambre From the build.ninja files, I can say that the changes were not taken into account because I give you erroneous changes (sorry for that):
the variable to be set is CMAKE_LINK_DEPENDS_USE_LINKER to FALSE.
For the other change, you have to directly hack the CMake config: file Modules/Platform/Linker/Linux-LLD.cmake and comment out the line set(CMAKE_${lang}_LINK_LIBRARIES_PROCESSING ORDER=REVERSE DEDUPLICATION=ALL) or change DEDUPLICATION value to SHARED. Both give the same result.
Is it possible for you to try a build of your environment but with the linker from the stable version (i.e. 19.1.3)? This check will enable to exonerate the development version of the linker.
Using LLD 19.1.3 from Debian (1:19.1.3-2 to be specific) still exhibits the issue.
the variable to be set is CMAKE_LINK_DEPENDS_USE_LINKER to FALSE.
Now, the DEDUPLICATION=ALL configuration should be operational with LLVM linker due to the linker design, paragraph Efficient archive file handling. So, from my point of view, this is a bug in the LLVM linker.
@tambre After thinking about this problem, I am not sure to understand how you produce the bug. Can you specify which toolchain (i.e. which compiler and version) you are using to compile the LLVM sources?
My concern is about the versions displayed in `CMakeCXXCompiler.cmake`. It shows up 20.0.0, not 19.* or what ever, so I deduce that you are not using a stable version of the toolchain to compile your developments...
I was initially using LLVM tip-of-the-tree I built myself together with the full LLVM toolchain (LLD, libc++, libc++abi, libunwind, etc.).
I've now been able to reproduce it with Debian's official LLVM 19.1.3 release after I realized I needed to specify -DCMAKE_LINKER_TYPE=LLD for it to use LLD.
I built LLVM 18.1.8 using Debian's LLVM 19.1.3 and used that to compile LLVM. The issue still reproduces.
So this problem isn't an issue introduced in LLVM's master since last release or even within the last 2 releases. I'll start a bisect to figure out which LLVM commit since the last release in combination with the CMake 3.31 change caused the breakage. LLVM takes a while to compile to check for the issue so I'll report back sometime tomorrow.
@tambre@brad.king I finally identified the problem: The order of archive libraries seems sensible: I was able to successfully link the library libclang-cpp.so by setting the policy CMP0179 to TRUE.
So the solution is to update the file cmake/Modules/CMakePolicy.cmake:
-- a/cmake/Modules/CMakePolicy.cmake+++ b/cmake/Modules/CMakePolicy.cmake @@ -37,4 +37,7 @@ endif() \# building with the Apple linker. if(POLICY CMP0156) cmake_policy(SET CMP0156 NEW) + if(POLICY CMP0179) + cmake_policy(SET CMP0179 NEW) + endif()endif()
@brad.king Now I am not sure if we have to do something on the CMake side, except, maybe, activate static library deduplication only if CMP0179 is NEW.
@marc.chevrier Will you submit the solution as a patch to LLVM yourself or do you want me to? Or will the change you mentioned in CMake be the fix? This seems like a CMake regression considering the strong backwards compatibility CMake tends to lean towards.
I agree, CMake should be as compatible as possible, but independently of what will be possible on the CMake side, I think it is anyway a good point to update the policy configuration of LLVM.
For the patch I suggest, I think you will be more comfortable than me to submit it to LLVM project. And maybe some investigation should be done on LLVM side: why the order of static libraries matter?
FYI, I just try to build, with the LLVM compiler (not the AppleClang), on macOS where all libraries are deduplicated. The library can be successfully generated. Of course, the linker is the apple one (lld is not available on macOS) but this tends to demonstrate that lld has a not so good behavior...
As I understand it would now be nice to file a bug against LLD. Ideally I'd reference it also in the commit message before merging. @marc.chevrier Do you have enough insight into the issue now to maybe come up with a minimal repro for the LLD guys? You'd probably also be able to word the exact link order issue and why it's unexpected better than me.
Unfortunately, the few tries I did didn't show the problem. In fact, the problem is about the generation of the library libLLVM.so. So, using CMake 3.31 and by playing with policy CMP0179, it is easy to get the two link commands for investigation. It is a bit painful but, for now, I have no alternative...
I just finish some other tests and the problem exists only for ELF binary format. LLD on Windows (ld.lld or lld-link, COFF format) or Apple (I built the linker on this platform, ld64.lld, MachO format) do not show up any problem.
So I think I will create a bug on LLVM project with what we have today. I think the fact that there is no small test to reproduce the problem is not a big deal because the problem can be reproduced with LLVM itself.
Let me know once you've created the issue so I can add a reference to it in my PR. Currently the reviewers didn't like the solution of CMP0179=NEW surprisingly.
Correct, it's a regression.
The exact same source code with CMP0156=NEW compiled until 3.31.0.
Setting CMP0156=OLD works around the issue in CMake 3.31.0 proving it's at fault.
Before 3.31, there is no way to distinguish, mainly on Linux, between `GNU` and `LLD` linkers, so deduplication was not applied to these platforms (as a result, CMP0156 has no effect). With the new linker infrastructure, we are able to know if GNU or LLD linker is used, so deduplication is applied when LLD linker is used, regardless of the CMP0179 state.
I agree, this not a correct behavior, I will provide the following fix for 3.31.1: On the impacted platforms, deduplication will occur only ifCMP0156andCMP0179 are set to NEW.
But the fact that the compilation of LLVM fails is due to a bug in the ELF backend of the linker.
And, unfortunately no, I was not able to reproduce the problem on a simple example.