[llvm-dev] CMake vs. autotools output differences
Andrew Wilkins via llvm-dev
llvm-dev at lists.llvm.org
Mon Aug 31 00:16:08 PDT 2015
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.
On Fri, 28 Aug 2015 at 00:25 Reid Kleckner <rnk at google.com> wrote:
> 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.
> On Thu, Aug 27, 2015 at 5:58 AM, Andrew Wilkins via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> 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
>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>> 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
>> libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2
>> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
>> 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:
>> (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?
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev