[lldb-dev] CMake & BUILD_SHARED_LIBS
axwalk at gmail.com
Mon Jun 1 00:55:11 PDT 2015
On Mon, 1 Jun 2015 at 11:06 Vince Harron <vince at nethacker.com> wrote:
> Hi Andrew,
> We're not testing that configuration so I'm not surprised that you're
> hitting problems. I'd like to look into it but we're working towards a
> release now and this isn't the most critical issue. For today, I recommend
> building without this flag.
No worries. When would be a good time to ping back? I was hoping to get the
packaging updated for 3.7, but that may be too aggressive, and not leave
enough time for bug fixing.
Also, in case I wasn't clear: I have changes ready, I just thought it might
be polite to bring it up here first, since I've not contributed before.
Building without the flag isn't really an option for Debian packaging. The
autotools-based build already links LLDB libs against libLLVM.so, and it
would be best to preserve that.
> On Sun, May 31, 2015 at 12:18 AM, Andrew Wilkins <axwalk at gmail.com> wrote:
>> I'm looking into updating the LLVM Debian packaging to use CMake instead
>> of autotools. I've hit some issues in building LLDB to do with the use of
>> BUILD_SHARED_LIBS. I thought I should email the list before proposing any
>> changes, as described below.
>> Many of the libraries in LLDB are not specified as being shared or static
>> in the CMake files. If you set BUILD_SHARED_LIBS, then it will attempt to
>> build them as shared; this fails due to undefined library dependencies. I
>> looked at adding them, but found there were some circular dependencies
>> which made it a bit messy. Also, it doesn't seem very useful to build them
>> as shared objects. Since the Makefiles only support building the internal
>> libraries as static, I figure the CMake files should be updated to do the
>> With the internal libraries built as static archives, then lldb will
>> build successfully (with some minor dependency additions; pthread, dl, and
>> LLVM's runtimedyld component). There are then some issues with loading the
>> Python extension module. The extension module is a symlink to liblldb.so,
>> whose RPATH entries aren't valid relative to the symlink target. This can
>> be resolved by adding a symlink from lib/python<version>/site-packages/lib
>> to lib.
>> Any issues? If not, I'll send a patch through soon.
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev