CMake vs. autotools output differences

Project Infrastructure LLVM Dev List Archives
#1

Hello,

I’ve spent some time hacking up the Debian packaging to use CMake instead of autotools; it’s still a work in progress, but it works. It’s a bit of a mess, though, primarily because there are differences in the output of the CMake and autotools builds.

On my Ubuntu machine, the dependencies for clang-3.6 look like this:
$ ldd /usr/bin/clang-3.6
linux-vdso.so.1 => (0x00007ffc7af57000)
libLLVM-3.6.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1 (0x00007fe47eac3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe47e8a5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe47e596000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe47e380000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe47dfb6000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe47dd9b000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fe47db93000)
libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007fe47d959000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fe47d730000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe47d52c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe47d224000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe480aa5000)

Using CMake with BUILD_SHARED_LIBS, it looks like this:
http://paste.ubuntu.com/12205368/
(the fact that I used pastebin is a hint)

The main difference is the many LLVM/Clang shared library dependencies, rather than just one. It’s preferred that each shared library is packaged separately, but this would be a bit of a maintenance nightmare; so that would mean one package with many shared libraries in it (more likely, one for all clang shared libraries, and one for all LLVM).

Are the differences between them intentional? Is there any room for change – to have the CMake-build tools link against the monolithic libLLVM as in autotools?

Second, Debian packages want both shared objects and static archives. BUILD_SHARED_LIBS means one or the other. Is there any reason why it would be a bad idea to modify add_llvm_library to create targets for both static and shared, if not specified?

Cheers,
Andrew

#2

We have a way to produce a libLLVM.so (https://llvm.org/bugs/show_bug.cgi?id=15493), but we do not have a way yet for clang to link against it. It’s similar to the situation of clang and libclang (https://llvm.org/bugs/show_bug.cgi?id=23749).

I really think we just need to push through the cmake jungle and make libLLVM.so and libclang.so into real libraries consumed by the various LLVM tools. I think it’s the right granularity for most users, even if it’s not right for everyone. It’s clearly what distro packagers want.

#3

Accidentally replied, instead of reply-all:

Okay. I’m working through a smallish change to add_llvm_executable that links to > libLLVM.so instead of the component libs. So far so good, and I think it’s a fairly non-intrusive > change. I’ll propose something soon if it works out.

And if anyone’s interested, I’ve just posted http://reviews.llvm.org/D12488. This takes care of libLLVM, but not libclang.

Cheers,
Andrew