Ismail Donmez via llvm-dev
2016-Jan-19 17:29 UTC
[llvm-dev] Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8
Hi, On Tue, Jan 19, 2016 at 7:18 PM, Chris Bieneman <beanz at apple.com> wrote:> The LLVM libraries are not API stable (especially not the ones you generate with BUILD_SHARED_LIBS). Those libraries are really not intended to ship.I know that's why I need them versioned. Currently we (openSUSE) ship libLLVM package which will install libLLVMFooBar.so.3.7 files and llvm-devel package will ship unversioned libLLVMFooBar.so. So, any application linking against LLVM generates a dependency against the versioned libLLVMFooBar.so.3.7 and not against the unversioned library. This way when we ship the new libLLVM 3.8 old application will have to be recompiled to correctly link against the new LLVM LLVM 3.7 and before did this correctly and 3.8 should not break this. As I said in another mail I tried -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON but it's not currently usable as it is. Thanks, ismail
Chris Bieneman via llvm-dev
2016-Jan-19 18:09 UTC
[llvm-dev] Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8
I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. Either way, patches welcome. -Chris> On Jan 19, 2016, at 9:29 AM, Ismail Donmez <ismail at i10z.com> wrote: > > Hi, > > On Tue, Jan 19, 2016 at 7:18 PM, Chris Bieneman <beanz at apple.com> wrote: >> The LLVM libraries are not API stable (especially not the ones you generate with BUILD_SHARED_LIBS). Those libraries are really not intended to ship. > > I know that's why I need them versioned. Currently we (openSUSE) ship > libLLVM package which will install libLLVMFooBar.so.3.7 files and > llvm-devel package will ship unversioned libLLVMFooBar.so. > > So, any application linking against LLVM generates a dependency > against the versioned libLLVMFooBar.so.3.7 and not against the > unversioned library. This way when we ship the new libLLVM 3.8 old > application will have to be recompiled to correctly link against the > new LLVM > > LLVM 3.7 and before did this correctly and 3.8 should not break this. > As I said in another mail I tried -DLLVM_BUILD_LLVM_DYLIB=ON > -DLLVM_LINK_LLVM_DYLIB=ON but it's not currently usable as it is. > > Thanks, > ismail
Ismail Donmez via llvm-dev
2016-Jan-26 16:15 UTC
[llvm-dev] Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8
Hi, On Tue, Jan 19, 2016 at 8:09 PM, Chris Bieneman <beanz at apple.com> wrote:> I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. > > Either way, patches welcome.This seems to be due to your commit http://reviews.llvm.org/D13841 , the problem is I don't get properly versioned symlinks even after install. All I get is bare libLLVMFooBar.so files.
Apparently Analagous Threads
- Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8
- Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8
- Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8
- Problem with the way BUILD_SHARED_LIBS=ON handled in llvm 3.8
- Building SVN head with CMake - shared libraries?