<div dir="ltr">We have a way to produce a libLLVM.so (<a href="https://llvm.org/bugs/show_bug.cgi?id=15493">https://llvm.org/bugs/show_bug.cgi?id=15493</a>), but we do not have a way yet for clang to link against it. It's similar to the situation of clang and libclang (<a href="https://llvm.org/bugs/show_bug.cgi?id=23749">https://llvm.org/bugs/show_bug.cgi?id=23749</a>).<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 5:58 AM, Andrew Wilkins via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>On my Ubuntu machine, the dependencies for clang-3.6 look like this:</div><div>$ ldd /usr/bin/clang-3.6</div><div> linux-vdso.so.1 => (0x00007ffc7af57000)</div><div> libLLVM-3.6.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-3.6.so.1 (0x00007fe47eac3000)</div><div> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe47e8a5000)</div><div> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe47e596000)</div><div> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe47e380000)</div><div> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe47dfb6000)</div><div> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe47dd9b000)</div><div> libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fe47db93000)</div><div> libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007fe47d959000)</div><div> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fe47d730000)</div><div> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe47d52c000)</div><div> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe47d224000)</div><div> /lib64/ld-linux-x86-64.so.2 (0x00007fe480aa5000)</div><div><br></div><div>Using CMake with BUILD_SHARED_LIBS, it looks like this:</div><div> <a href="http://paste.ubuntu.com/12205368/" target="_blank">http://paste.ubuntu.com/12205368/</a></div><div>(the fact that I used pastebin is a hint)</div><div><br></div><div>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).</div><div><br></div><div>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?<br></div><div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div>Andrew</div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>