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

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!

> 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"
Could you try appending ``-DLLVM_LINK_LLVM_DYLIB=ON`` to your CMake
invocation? It looks like lldb is using the ``llvm_add_library()``
function in the ``cmake/modules/AddLLVM.cmake`` (LLVM source tree)
which uses ``LLVM_LINK_LLVM_DYLIB`` (and a few other variables) to
decide whether to link against LLVM's static component libraries or
the monolithic shared library. I could be wrong on this though but it
should
be pretty quick to check.

Out of curiosity though if you're building packages on openSUSE why do
you need a standalone build? I thought the normal way to do this was
to build everything and then generate split packages?

Thanks,
Dan.

On Sat, Jan 16, 2016 at 9:33 PM, Dan Liew <dan at su-root.co.uk>
wrote:
>> 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"
>
> Could you try appending ``-DLLVM_LINK_LLVM_DYLIB=ON`` to your CMake
> invocation? It looks like lldb is using the ``llvm_add_library()``
> function in the ``cmake/modules/AddLLVM.cmake`` (LLVM source tree)
> which uses ``LLVM_LINK_LLVM_DYLIB`` (and a few other variables) to
> decide whether to link against LLVM's static component libraries or
> the monolithic shared library. I could be wrong on this though but it
> should
> be pretty quick to check.
I already use  -DLLVM_BUILD_LLVM_DYLIB=ON  -DLLVM_LINK_LLVM_DYLIB=ON
> Out of curiosity though if you're building packages on openSUSE why do
> you need a standalone build? I thought the normal way to do this was
> to build everything and then generate split packages?
Nice question. Since Mesa depends on llvm and Mesa is very crucial to
a distro bootstrap, adding any new dependency to llvm creates a
circular dependency which we can't have. And lldb itself brings python
dependency which complicates the issue (python has a Mesa dependency).
I may try to pre-generate files with swig to remove the dependency but
it would be nice if this worked as expected.

Thanks!

ismail