llvm dev - Aug 2015 - CMake vs. autotools output differences

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/61ff5e18/attachment.html>

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/20150827/7b7c934a/attachment.html>

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>