Bug 1388200

The problem with that is that "llvm-config --shared-mode" always uses static if the static libraries are present, which also applies to "llvm-config --libs" etc.

Maybe the libLLVMSupport.a library should be moved into the -devel package then (it seems to not have a shared variant)?

This is for cmake, right?  I think libLLVMSupport.a is just the first one it tries to import, but it appears to want all of them.

Maybe llvm-cmake ought to be its own package?  That could require everything, but still leave llvm-devel minimal for non-cmake shared builds.  However, I don't see any precedence where other package split this out.

Wait, there are no shared versions of the non-libLLVM (and a few other) libraries at all; that's why llvm-config --shared-mode always uses static libs: there are no shared versions of most of them. The static libs should probably just be part of the -devel package and -static be obsoleted.

AIUI, the shared libLLVM.so is a conglomerate of all components.  When you don't have llvm-static present, then "llvm-config --libs" gives you "-lLLVM-3.9.0".

I just learned via a rust issue[1] that in LLVM 3.9, llvm-config finally gives precedence to shared linking when both shared and static are available.  This solves my main concern with pulling in llvm-static.  It now even has explicit options for forcing a mode, --link-shared or --link-static.

[1] https://github.com/rust-lang/rust/issues/34486#issuecomment-257139448


A smaller concern is that llvm-static bloats the buildroot a bit, currently being a 16MB rpm that's 95MB installed.  By policy *most* Fedora packages should not be using these at all, so it's just a waste of space to require it everywhere.

It would be nicer if the cmake scripts could deal with the static libraries maybe not being present, but I don't know how feasible that is.

LLVM would have to use a different export file for the static libraries than the shared libraries and implement some logic in LLVMConfig.cmake to deal with it being optional. It shouldn't be too hard to do; the LLVMConfig.cmake would then probably be best to do a COMPONENTS bit to conditionally expect those to be there or not.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This has been fixed in rahwide by splitting out the cmake export files into a static and non-static exports.  The static export file is now distributed with the llvm-static package, so find_package(LLVM) should work without the llvm-static package.

clang-4.0.1-4.fc26 compiler-rt-4.0.1-1.fc26 libcxx-4.0.1-3.fc26 libcxxabi-4.0.1-3.fc26 lld-4.0.1-4.fc26 lldb-4.0.1-3.fc26 llvm-4.0.1-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b0bd12720a

clang-4.0.1-4.fc26, compiler-rt-4.0.1-1.fc26, libcxx-4.0.1-3.fc26, libcxxabi-4.0.1-3.fc26, lld-4.0.1-4.fc26, lldb-4.0.1-3.fc26, llvm-4.0.1-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b0bd12720a

clang-4.0.1-4.fc26, compiler-rt-4.0.1-1.fc26, libcxx-4.0.1-3.fc26, libcxxabi-4.0.1-3.fc26, lld-4.0.1-4.fc26, lldb-4.0.1-3.fc26, llvm-4.0.1-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.