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

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

On Sat, Jan 16, 2016 at 10:21 PM, Ismail Donmez <ismail at i10z.com>
wrote:
> I may try to pre-generate files with swig to remove the dependency but
> it would be nice if this worked as expected.
Forgot this line, I thought swig was the problematic dep, its not.

On 16 January 2016 at 20:21, Ismail Donmez <ismail at i10z.com>
wrote:
> 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
That'll teach me to suggest something without actually trying it. Then
I might have actually noticed you're already using that flag!

Let me see if I can reproduce this. Are you building on LLVM trunk on
the 3.8 release branch?

>> 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.
It's not entirely clear to me why adding a package (build or runtime?)
dependency to LLVM creates a circular dependency.
If you build llvm, clang and lldb and make split packages from the
result you have a runtime dependency graph that is a tree with LLVM at
the root.
Maybe it's best not to digress. I agree that the standalone build of
lldb should work as expected.

Thanks,
Dan.

Hi,

On Sun, Jan 17, 2016 at 1:04 PM, Dan Liew <dan at su-root.co.uk>
wrote:
> On 16 January 2016 at 20:21, Ismail Donmez <ismail at i10z.com>
wrote:
>> 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
>
> That'll teach me to suggest something without actually trying it. Then
> I might have actually noticed you're already using that flag!
>
> Let me see if I can reproduce this. Are you building on LLVM trunk on
> the 3.8 release branch?
Trying the 3.8 branch atm.
>>> 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.
>
> It's not entirely clear to me why adding a package (build or runtime?)
> dependency to LLVM creates a circular dependency.
> If you build llvm, clang and lldb and make split packages from the
> result you have a runtime dependency graph that is a tree with LLVM at
> the root.
> Maybe it's best not to digress. I agree that the standalone build of
> lldb should work as expected.
The cycle is

Mesa -> llvm -> python -> Mesa