The ./configure system has the option --enable-shared, which creates a libLLVM-version.so file, e.g. libLLVM-3.3.so. There is a similarly named option available from CMake. This option builds .so files instead of .a files, but doesn't create the libLLVM-version.so file, which is required for certain programs, e.g. the OpenShadingLanguage project. I request that either this existing CMake option or a new option would allow the creation of libLLVM-version.so with CMake.
To be honest, I'd rather work on getting rid of this file completely. There's no sane way of getting the name of this file, and llvm-config only focuses on the split libraries.
I'm no cmake expert, but the cmake+shared build produces a libclang-3.x.{so,dylib} that links all of the constituent libclang* libs. Couldn't that be done with the libLLVM* set?
Is this out of scope or not, as suggested by Michał Górny? If not, it can be done.
Speaking from working with the Haskell bindings (and echoing Michał's point) and in other situations: it sucks having libLLVM-$version.so and then the split static libraries, and there's no way to figure any of it out from llvm-config (and I wouldn't suggest llvm-config to deal with it). Also, it makes it much easier if one wants to support either the dynamic or static compilation in a client of the LLVM libraries. If they have the same names, then the -static flag should work as one would expect (I believe). In short: libLLVM-$version.so seems to invite hacks in consumers of the library.
Scott, At least from a point of view of cmake consuming the library, the file name on disk is not relevant. Whether shared or static, a symbolic name will be used in cmake code, so not explicit handling of static/shared for the file name will be needed. Your comment might be deserving of a separate bug report to reach the right people.
> At least from a point of view of cmake consuming the library, the file name > on disk is not relevant. Whether shared or static, a symbolic name will be > used in cmake code, so not explicit handling of static/shared for the file > name will be needed. Perhaps I misunderstood the suggestion: would you want to provide an option to generate libLLVM-$version.so to replace the more granular *.so's, or to generate both?
Ah, sorry, I think I misunderstood. Actually I can't imagine why OpenShadingLanguage thinks they need the -$version.so file. That might just be a misunderstanding too? > Perhaps I misunderstood the suggestion: would you want to provide an > option to generate libLLVM-$version.so to replace the more > granular *.so's, or to generate both? I'll leave that up to the llvm developers to decide.
I am working for this. http://llvm-reviews.chandlerc.com/D2942
(In reply to comment #8) > I am working for this. > http://llvm-reviews.chandlerc.com/D2942 Is the proposal to completely replace the granular lib*.so's with libLLVM-version.so and remove the ability to generate the granular lib*.so's ? Because that would re-break llvm-config, it's already broken for the autotools build (unless this has recently changed). See Bug #6823.
I don't have a plan to deprecate BUILD_SHARED_LIBS.
I've submitted patches for review: http://reviews.llvm.org/D6157
Fixed by: r229720: Enable standard so versioning for libLLVM.
(In reply to comment #12) > Fixed by: > r229720: Enable standard so versioning for libLLVM. Looking at the diff, shouldn't SOVERSION be set to "${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}" instead of just "${LLVM_VERSION_MAJOR}" since ABI changes with each minor LLVM release (e.g. 3.5 -> 3.6)?
Yes, that's a really good catch. I'll fix that today.
Fixed r230981.