This is how the breakage was introduced: https://github.com/gentoo/gentoo/commit/04d86e2eab73e1bc80940c4cb7630a681172fd1d "Building with link time optimization requires cooperation from the system linker. LTO support on Linux systems is available via the gold linker which supports LTO via plugins." - https://www.llvm.org/docs/GoldPlugin.html So Clang needs "ld.gold" on Linux to be able to do LTO. Reproducible: Always
No, it doesn't. It works fine with LLD. gold is considered dead upstream and nobody is working on it.
> No, it doesn't. # rg 'fuse-ld=gold' /usr/share/ /usr/share/cmake/Modules/Compiler/Clang.cmake 86: set(CMAKE_${lang}_LINK_OPTIONS_IPO "-fuse-ld=gold")
(In reply to Ștefan Talpalaru from comment #2) > > No, it doesn't. > > # rg 'fuse-ld=gold' /usr/share/ > /usr/share/cmake/Modules/Compiler/Clang.cmake > 86: set(CMAKE_${lang}_LINK_OPTIONS_IPO "-fuse-ld=gold") Quoting a random line from CMake doesn't contradict what I said.
The region which matches that in there for me is: ``` if(ANDROID AND NOT CMAKE_ANDROID_NDK_VERSION VERSION_GREATER_EQUAL "22") # https://github.com/android-ndk/ndk/issues/242 set(CMAKE_${lang}_LINK_OPTIONS_IPO "-fuse-ld=gold") endif() ``` We are not on Android. Does it match another region for you, or did you make an error?
Also, llvmgold works just fine with ld.bfd last I know of even if that page does not "recommend" it (imagine that statement is dated) -- albeit, as a sam said, should really be using ld.lld if going to do clang+lto. This is the more tested path, and lld is the default linker on a llvm profile. (when using clang+lto+lld you do not even need llvmgold installed, albeit doesn't hurt to keep it for the rare packages that really needs ld.bfd, these packages tend to be broken with ld.gold as well)
