On Mon, 1 Jun 2015 at 11:06 Vince Harron <vi...@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. Cheers, Andrew Sincerely, > > Vince > > On Sun, May 31, 2015 at 12:18 AM, Andrew Wilkins <axw...@gmail.com> wrote: > >> Hi, >> >> 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 >> same. >> >> 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. >> >> Cheers, >> Andrew >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
