llvm dev - Jan 2016 - Building SVN head with CMake - shared libraries?

> On Jan 14, 2016, at 11:43 AM, Ismail Donmez <ismail at i10z.com>
wrote:
> 
> On Thu, Jan 14, 2016 at 9:31 PM, Chris Bieneman via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>> 
>> On Jan 14, 2016, at 11:22 AM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
>> 
>> 
>> On Jan 14, 2016, at 9:38 AM, Chris Bieneman via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> 
>> 
>> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk>
wrote:
>> 
>> On 14 January 2016 at 11:24, David Jones via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> 
>> Thanks - I'll try this tonight.
>> 
>> Assuming it works, should these variables be added to the docs at
>> http://llvm.org/docs/CMake.html ?
>> 
>> 
>> Yes.
>> 
>> 
>> It probably makes sense to add LLVM_BUILD_LLVM_DYLIB, but I would
discourage
>> adding BUILD_SHARED_LIBS to that document. BUILD_SHARED_LIBS is rarely
what
>> people actually want, and a lot of people gravitate to it because the
>> wording is similar to the autoconf —enable-shared flag.
>> 
>> 
>> Considering that BUILD_SHARED_LIBS is rarely what people want, wouldn’t
it
>> make sense to document it to explicitly discourage people from using it
and
>> avoid them surprising behavior?
>> 
>> 
>> Honestly, I’m not sure *anyone* actually wants that behavior, and I’d
kinda
>> like to remove the option entirely.
> 
> Do I understand it correctly that LLVM_BUILD_LLVM_DYLIB produces a one
> big libLLVM.so and a lot of static libraries? Btw currently for
> openSUSE builds we do utilize BUILD_SHARED_LIBS so please don't remove
> it.
I’m kinda scared that you’re using it. What are you trying to accomplish that
you are using it? Generally having LLVM split among that many dynamically loaded
libraries results in significant performance regressions.

-Chris
> 
> Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160114/ac500738/attachment.html>

Hi,

On Fri, Jan 15, 2016 at 12:59 AM, Chris Bieneman <beanz at apple.com>
wrote:
> I’m kinda scared that you’re using it. What are you trying to accomplish
> that you are using it? Generally having LLVM split among that many
> dynamically loaded libraries results in significant performance
regressions.
When we first switched to cmake it was the only option to produce
shared libraries, hence we went with it. I am testing with
-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON atm, and will let
you know if any problem arises.

Thanks!

On Fri, Jan 15, 2016 at 11:05 AM, Ismail Donmez <ismail at i10z.com>
wrote:
> Hi,
>
> On Fri, Jan 15, 2016 at 12:59 AM, Chris Bieneman <beanz at apple.com>
wrote:
>> I’m kinda scared that you’re using it. What are you trying to
accomplish
>> that you are using it? Generally having LLVM split among that many
>> dynamically loaded libraries results in significant performance
regressions.
>
> When we first switched to cmake it was the only option to produce
> shared libraries, hence we went with it. I am testing with
> -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON atm, and will let
> you know if any problem arises.
And one immediate "problem" shows up. I ended up with

libLLVM-3.9svn.so

and

libclang.so
libclang.so.3.9

LLVM's shared lib naming looks wrong.

Hi again,

On Fri, Jan 15, 2016 at 11:05 AM, Ismail Donmez <ismail at i10z.com>
wrote:
> Hi,
>
> On Fri, Jan 15, 2016 at 12:59 AM, Chris Bieneman <beanz at apple.com>
wrote:
>> I’m kinda scared that you’re using it. What are you trying to
accomplish
>> that you are using it? Generally having LLVM split among that many
>> dynamically loaded libraries results in significant performance
regressions.
>
> When we first switched to cmake it was the only option to produce
> shared libraries, hence we went with it. I am testing with
> -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON atm, and will let
> you know if any problem arises.
I am trying to enable this on openSUSE but it seems to break
standalone lldb (note that we don't ship static libs):

cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
-DCMAKE_CXX_FLAGS=-stdlib=libc++ -DLLVM_BUILD_LLVM_DYLI
B=ON -DLLVM_LINK_LLVM_DYLIB=ON -DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_LIBDIR_SUFFIX=64 -DLLDB_PA
TH_TO_LLVM_BUILD=/usr -DLLDB_PATH_TO_CLANG_BUILD=/usr
-DLLVM_RUNTIME_OUTPUT_INTDIR=/home/abuild/rpmbuild/BUILD/lldb-3.8.0/buil
d/bin
-DLLVM_LIBRARY_OUTPUT_INTDIR=/home/abuild/rpmbuild/BUILD/lldb-3.8.0/build/lib64
-DPYTHON_VERSION_MAJOR=2 -DPYTHON_VERSIO
N_MINOR=7 -G Ninja ..

[...]

CMake Error at /usr/share/llvm/cmake/LLVMExports.cmake:1011 (message):
  The imported target "LLVMSupport" references the file

      "/usr/lib64/libLLVMSupport.a"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/usr/share/llvm/cmake/LLVMExports.cmake"

   but not all the files it references.

Call Stack (most recent call first):
  /usr/share/llvm/cmake/LLVMConfig.cmake:178 (include)
  cmake/modules/LLDBStandalone.cmake:76 (include)
  CMakeLists.txt:3 (include)


-- Configuring incomplete, errors occurred!