Created attachment 906947 [details] emerge --info [230/2009] : && /usr/lib/llvm/18/bin/clang++ -march=native -O2 -pipe -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -pedantic -Wno-long-long -Wno-nested-anon-types -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--as-needed -Wl,--color-diagnostics -Wl,--gc-sections lib/Support/CMakeFiles/obj.clangSupport.dir/RISCVVIntrinsicUtils.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ASTTableGen.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangASTNodesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangASTPropertiesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangAttrEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangCommentCommandInfoEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangCommentHTMLNamedCharacterReferenceEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangCommentHTMLTagsEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangDataCollectorsEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangDiagnosticsEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOpcodesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOpenCLBuiltinEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOptionDocEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangSACheckersEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangSyntaxEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangTypeNodesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/MveEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/NeonEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/RISCVVEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/SveEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/TableGen.cpp.o -o bin/clang-tblgen -L/usr/lib/llvm/18/lib64 -Wl,-rpath,"\$ORIGIN/../lib64:/usr/lib/llvm/18/lib64:" /usr/lib/llvm/18/lib64/libLLVMSupport.a /usr/lib/llvm/18/lib64/libLLVMTableGen.a /usr/lib/llvm/18/lib64/libLLVMSupport.a -lrt -ldl -lm /usr/lib64/libz.so /usr/lib64/libzstd.so /usr/lib64/libtinfo.so /usr/lib/llvm/18/lib64/libLLVMDemangle.a && : FAILED: bin/clang-tblgen : && /usr/lib/llvm/18/bin/clang++ -march=native -O2 -pipe -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -pedantic -Wno-long-long -Wno-nested-anon-types -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--as-needed -Wl,--color-diagnostics -Wl,--gc-sections lib/Support/CMakeFiles/obj.clangSupport.dir/RISCVVIntrinsicUtils.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ASTTableGen.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangASTNodesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangASTPropertiesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangAttrEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangCommentCommandInfoEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangCommentHTMLNamedCharacterReferenceEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangCommentHTMLTagsEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangDataCollectorsEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangDiagnosticsEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOpcodesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOpenCLBuiltinEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOptionDocEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangSACheckersEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangSyntaxEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangTypeNodesEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/MveEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/NeonEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/RISCVVEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/SveEmitter.cpp.o utils/TableGen/CMakeFiles/clang-tblgen.dir/TableGen.cpp.o -o bin/clang-tblgen -L/usr/lib/llvm/18/lib64 -Wl,-rpath,"\$ORIGIN/../lib64:/usr/lib/llvm/18/lib64:" /usr/lib/llvm/18/lib64/libLLVMSupport.a /usr/lib/llvm/18/lib64/libLLVMTableGen.a /usr/lib/llvm/18/lib64/libLLVMSupport.a -lrt -ldl -lm /usr/lib64/libz.so /usr/lib64/libzstd.so /usr/lib64/libtinfo.so /usr/lib/llvm/18/lib64/libLLVMDemangle.a && : ld.lld: error: /usr/lib/llvm/18/lib64/libLLVMSupport.a(blake3.c.o): Invalid attribute group entry (Producer: 'LLVM19.1.2+libcxx' Reader: 'LLVM 18.1.8+libcxx') clang++: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed.
The workaround is an environment file: CC="clang-19" CXX="clang++-19" CPP="clang-cpp-19" AR="/usr/lib/llvm/19/bin/llvm-ar" NM="/usr/lib/llvm/19/bin/llvm-nm" RANLIB="/usr/lib/llvm/19/bin/llvm-ranlib" sys-devel/clang-17.0.6 build succeeds without the file above.
Created attachment 906948 [details] build.log
Created attachment 906949 [details] build.log
There's not really anything that can be done here with self-hosted Clang. It's yet another reason that LLVM should be built as a monobuild.
What's the reason for `llvm_prepend_path "${LLVM_MAJOR}"` in multilib_src_configure? That's what's tripping things up, as it's making a non-default Clang appear in PATH before the system-wide default Clang. What we want is to compile Clang X, using the compiler from Clang Y, while referencing the headers from LLVM X. Then we want to link Clang X, using the linker plugin from LLVM Y, while linking to the shared libraries from LLVM X. The way to do that isn't to go messing around with PATH. The following change to the ebuild fixes the issue for me: --- sys-devel/clang/clang-18.1.8-r6.ebuild +++ sys-devel/clang/clang-18.1.8-r6.ebuild @@ -255,12 +255,11 @@ } multilib_src_configure() { - llvm_prepend_path "${LLVM_MAJOR}" - local mycmakeargs=( -DDEFAULT_SYSROOT=$(usex prefix-guest "" "${EPREFIX}") -DCMAKE_INSTALL_PREFIX="${EPREFIX}/usr/lib/llvm/${LLVM_MAJOR}" -DCMAKE_INSTALL_MANDIR="${EPREFIX}/usr/lib/llvm/${LLVM_MAJOR}/share/man" + -DLLVM_CMAKE_DIR="${EPREFIX}/usr/lib/llvm/${LLVM_MAJOR}/$(get_libdir)/cmake" -DCLANG_CONFIG_FILE_SYSTEM_DIR="${EPREFIX}/etc/clang" # relative to bindir -DCLANG_RESOURCE_DIR="../../../../lib/clang/${LLVM_MAJOR}" What this accomplishes is to provide a hint to the find_package(LLVM …) call on line 31 of cmake/CMakeLists.txt about where to look for the configuration of the LLVM package upon which the Clang package being built depends. We want CMake to find the config for LLVM X, not the config for (the system-wide default) LLVM Y. Presumably that had been accomplished somewhat ham-fistedly by forcing the llvm-config from LLVM X to appear earlier in PATH than the system-wide default llvm-config, but doing that comes with a bunch of unwanted side effects when we actually want to build using the system-wide default Clang. It's cleaner just to tell CMake explicitly where to look for the config of the LLVM package to build against.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aec36c6fbd87fab890fc4e53fe7c39dee49fdda5 commit aec36c6fbd87fab890fc4e53fe7c39dee49fdda5 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-12-12 04:32:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-12 04:37:16 +0000 llvm-core/clang: drop llvm_prepend_path use The hackery with PATH here is wrong and it breaks building Clang itself with a different version of Clang (which is why we're looking at rejigging how the eclass works/replacing it with llvm-r1.eclass [0]). As suggested by Matt, use LLVM_CMAKE_DIR instead so that Clang finds the right version of LLVM to build against without any sort of nonsense messing with build tooling. [0] https://public-inbox.gentoo.org/gentoo-dev/d5489fa24ef3d1129540879e628120addb3af8ce.camel@gentoo.org/ Closes: https://bugs.gentoo.org/942314 Closes: https://bugs.gentoo.org/944788 Thanks-to: Matt Whitlock <gentoo@mattwhitlock.name> Signed-off-by: Sam James <sam@gentoo.org> llvm-core/clang/clang-18.1.8-r6.ebuild | 5 ++--- llvm-core/clang/clang-19.1.4.ebuild | 5 ++--- llvm-core/clang/clang-19.1.5.ebuild | 5 ++--- llvm-core/clang/clang-20.0.0.9999.ebuild | 5 ++--- llvm-core/clang/clang-20.0.0_pre20241207.ebuild | 5 ++--- 5 files changed, 10 insertions(+), 15 deletions(-)
Thank you, Matt.
meh, I see a bunch of other uses in llvm-*/*. Matt, would you be so kind to consider making a PR to drop those if that change works with older LLVM too?
(In reply to Sam James from comment #8) > meh, I see a bunch of other uses in llvm-*/*. Matt, would you be so kind to > consider making a PR to drop those if that change works with older LLVM too? llvm-core/lldb isn't slotted, so ideally users should always be building only the latest version of LLDB using the latest version of LLVM+Clang, and so users are unlikely to run into any mismatch there. However, it is, of course, possible to force building an older version of LLDB, and if the same older version of LLVM is installed on the system and was built using a newer version of Clang, then building the older version of LLDB will fail for the same reason as described in this bug. The fix is the same as for llvm-core/clang except that they named the variable differently: LLVM_DIR instead of LLVM_CMAKE_DIR. llvm-core/lld is slotted but apparently doesn't link to any static libraries from LLVM, so it doesn't matter whether the LLVM that it's linking against was built using a newer version of Clang than is being used to link the being-built LLD. However, the use of llvm_prepend_path *does* cause an older version of Clang to be used for compiling (and an older version of LLD to be used for linking) than the system-wide default version if CC/CXX specifies Clang/Clang++ without explicitly specifying a major version. The fix is the same as for llvm-core/clang. The various llvm-runtimes/* packages are in the same situation as llvm-core/lld and have the same fix except that llvm-runtimes/openmp has a CMake file that calls find_package(LLVM …) without specifying HINTS "${LLVM_CMAKE_DIR}". That's an upstream "oops." Hacking in a HINTS argument with sed allows the same fix to work there as well. I've applied fixes locally to all affected package versions and am currently building them all using Clang 19 to sniff test my changes. Once everything passes, I'll open a PR.
(In reply to Sam James from comment #8) > Matt, would you be so kind to > consider making a PR to drop those if that change works with older LLVM too? Sam, the next time you have the thought to ask me to take on something like this, please ask Michał instead. I am turning it over to him after having wasted more than an entire day trying to satisfy his demands.
