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

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.

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.

mentioned in issue llvm/llvm-bugzilla-archive#15732