CMake & BUILD_SHARED_LIBS

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/site-packages/lib to lib.

Any issues? If not, I’ll send a patch through soon.

Cheers,
Andrew

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.

Sincerely,

Vince

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

Yep, I confirm that it is needed to move the Debian & Ubuntu packages from autotools to cmake. For now, I have an important number of undefined symbols. Could you send your patch? I would be happy to test that. Thanks, Sylvestre

Sure, I’ve just uploaded it to Phabricator: http://reviews.llvm.org/D10157.

Vince, please feel free to ignore that one for now, as you’re busy. I don’t want to disrupt anyone’s work.

Cheers,
Andrew

Hi Andrew,

Thanks for the patch and thanks for your patience. The release is in 4-6 weeks but there are a lot of people on the team, someone will probably have a chance to look sooner.

Is there a deadline you are working against?

Vince

Hi Andrew,

Thanks for the patch and thanks for your patience. The release is in 4-6 weeks but there are a lot of people on the team, someone will probably have a chance to look sooner.

Is there a deadline you are working against?

No particular deadline. My ultimate goal is to get llgo (Go frontend for LLVM) packaged in Debian and Ubuntu. llgo only has CMake, and I don’t want to maintain both CMake and autotools. Packaging is meant to be moving to CMake anyway, so I’m seeing what I can do to help move that forward. I’d like to have the LLVM changes done by the 3.7 release if possible.

Cheers,
Andrew

My life would be somewhat improved as well if we could rely upon the CMake
builds everywhere. It would be great to see that happen by 3.7 as we're
looking to move some of our tools towards using LLVM 3.7 as a base.

- Bruce