I installed llvm/clang 10.0.0.9999 and there is virtually nothing in the lib dirs: # ls /usr/lib/llvm/10/lib64/ cmake libclang-cpp.so libclang-cpp.so.10 libclang.so libclang.so.10 libLLVM-10.0.0.so libLLVM-10.so libLLVMDemangle.a libLLVM.so libLLVMSupport.a libLLVMTableGen.a libLTO.so libLTO.so.10 libRemarks.so libRemarks.so.10 rogue ~ # ls /usr/lib/llvm/10/lib32/ cmake libclang-cpp.so libclang-cpp.so.10 libclang.so libclang.so.10 libLLVM-10.0.0.so libLLVM-10.so libLLVMDemangle.a libLLVM.so libLLVMSupport.a libLLVMTableGen.a libLTO.so libLTO.so.10 libRemarks.so libRemarks.so.10 rogue ~ # ls /usr/lib/llvm/10/libexec/ c++-analyzer ccc-analyzer rogue ~ # ls /usr/lib/llvm/10 bin include lib32 lib64 libexec share rogue ~ # ls /usr/lib/llvm/10/share/ clang man opt-viewer scan-build scan-view rogue ~ # ls /usr/lib/llvm/10/share/clang/ bash-autocomplete.sh clang-format-bbedit.applescript clang-format.el clang-format-sublime.py clang-include-fixer.py clang-rename.py index.js run-find-all-symbols.py clang-doc-default-stylesheet.css clang-format-diff.py clang-format.py clang-include-fixer.el clang-rename.el clang-tidy-diff.py run-clang-tidy.py rogue ~ # ls /usr/lib/llvm/10/bin/ bugpoint clang-doc count i686-pc-linux-gnu-clang-cpp-10 llvm-cvtres llvm-jitlink llvm-pdbutil llvm-symbolizer x86_64-pc-linux-gnu-clang c-index-test clang-extdef-mapping diagtool i686-pc-linux-gnu-llvm-config llvm-cxxdump llvm-lib llvm-PerfectShuffle llvm-tblgen x86_64-pc-linux-gnu-clang++ clang clang-format dsymutil llc llvm-cxxfilt llvm-link llvm-profdata llvm-undname x86_64-pc-linux-gnu-clang++-10 clang++ clang-import-test FileCheck lli llvm-cxxmap llvm-lipo llvm-ranlib llvm-xray x86_64-pc-linux-gnu-clang-10 clang++-10 clang-include-fixer find-all-symbols lli-child-target llvm-diff llvm-lto llvm-rc modularize x86_64-pc-linux-gnu-clang-cl clang-10 clang-move git-clang-format llvm-addr2line llvm-dis llvm-lto2 llvm-readelf not x86_64-pc-linux-gnu-clang-cl-10 clang-apply-replacements clang-offload-bundler hmaptool llvm-ar llvm-dlltool llvm-mc llvm-readobj obj2yaml x86_64-pc-linux-gnu-clang-cpp clang-change-namespace clang-offload-wrapper i686-pc-linux-gnu-clang llvm-as llvm-dwarfdump llvm-mca llvm-reduce opt x86_64-pc-linux-gnu-clang-cpp-10 clang-check clang-query i686-pc-linux-gnu-clang++ llvm-bcanalyzer llvm-dwp llvm-modextract llvm-rtdyld pp-trace x86_64-pc-linux-gnu-llvm-config clang-cl clang-refactor i686-pc-linux-gnu-clang++-10 llvm-cat llvm-elfabi llvm-mt llvm-size sancov yaml2obj clang-cl-10 clang-rename i686-pc-linux-gnu-clang-10 llvm-cfi-verify llvm-exegesis llvm-nm llvm-split sanstats yaml-bench clang-cpp clang-reorder-fields i686-pc-linux-gnu-clang-cl llvm-config llvm-extract llvm-objcopy llvm-stress scan-build clang-cpp-10 clang-scan-deps i686-pc-linux-gnu-clang-cl-10 llvm-cov llvm-ifs llvm-objdump llvm-strings scan-view clangd clang-tidy i686-pc-linux-gnu-clang-cpp llvm-c-test llvm-install-name-tool llvm-opt-report llvm-strip verify-uselistorder Reproducible: Always Steps to Reproduce: 1. emerge the librarys Actual Results: Many libs missing Expected Results: Many libs installed
This is the correct outcome. LLVM is now linking everything into those few libraries.
This seems to break mesa building for me though. Now mesa (9999) fails to build with: src/gallium/targets/opencl/meson.build:36:0: ERROR: C++ library 'clangCodeGen' not found
If I revert the changes to `multilib_src_install()` and `multilib_src_configure()` compared to the llvm-9 ebuild, everything seems to work again.
It also seems like at least clang-10.0.0_rc3 doesn't install binaries correctly either. I'm missing clang, clangd, clang-format in the global path. So a few other programs breaks for me as well. (LSP servers in particular)
I believe this bug is valid. This new "consolidated" library is actually optional, and is caused by switching the flag "-DBUILD_SHARED_LIBS" to "OFF" (it's always been "ON" in previous LLVM/clang ebuilds). This doesn't cause issues with LLVM/clang itself, but does cause issues when building things that link to it. qt-creator 4.12 beta for one and, according to this bug, Mesa in some cases. In the case of qt-creator, upstream is still hardcoding the multiple library names when linking. I tried creating symlinks, but that caused undefined references which suggests that the "consolidated" library isn't exporting everything the split libraries do. OpenMandriva (which uses clang by default for everything) still uses the old option: https://github.com/OpenMandrivaAssociation/llvm/blob/master/llvm.spec#L990 For a source-based distro like Gentoo (where packages usually require the "development" version of shared libraries to link against), this change is almost certain to cause problems going forward. Not many packages even support LLVM 10 yet (especially in stable), but given that other distros seem to be using the old flag value, I suspect this is going to come up more in the future.
(In reply to Tiernan Hubble from comment #5) > I believe this bug is valid. This new "consolidated" library is actually > optional, and is caused by switching the flag "-DBUILD_SHARED_LIBS" to "OFF" > (it's always been "ON" in previous LLVM/clang ebuilds). This flag is mentioned in bugs surrounding building mlir from source (not gentoo specific), you need to turn this off to enable building otherwise you get a ton or errors in the tablegen headers.
I just found this, from Fedora: https://fedoraproject.org/wiki/Changes/Stop-Shipping-Individual-Component-Libraries-In-clang-lib-Package Apparently "libclang-cpp.so" is the correct library to link against, so possibly creating symlinks to that one would work? It does mention multiple packages that will need to be fixed upstream, including Mesa, and that Fedora won't be switching to "-DBUILD_SHARED_LIBS=OFF" until they're all migrated. I'm not too familiar with mlir, but does it only depend on LLVM, or clang as well? i.e., would it work to only disable this flag for clang, since its libraries seem to be the ones causing issues? Although I'm not sure if that could cause dependency issues between clang and LLVM.
MLIR has just been added to LLVM as of v10. It's the basis of Google's IREE which is for machine learning on top of Vulkan (can also use ROCm and CUDA).
Also, Clang is migrating to MLIR which will then convert to LLVM IR. https://mlir.llvm.org/
I can confirm that symlinking works. What I did: for i in Format ToolingInclusions ToolingCore Rewrite Lex Basic; do ln -s libclang-cpp.so /usr/lib/llvm/10/lib64/libclang${i}.so; done Then dev-qt/qt-creator-4.8.2[clang] emerged without issue.
