[llvm-dev] CMake vs. autotools output differences

[Andrew Wilkins via llvm-dev]

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

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:
>
>> 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
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150831/59c651fe/attachment-0001.html>