[llvm] r187874 - Add support for linking against a curses library when available and

Chandler Carruth chandlerc at google.com
Wed Aug 7 14:32:57 PDT 2013

On Wed, Aug 7, 2013 at 2:09 PM, James Molloy <james at jamesmolloy.co.uk>wrote:

> Hi Chandler,
> I agree that all unix systems have curses or terminfo. However, it
> complicates distribution. Now, anyone who wants to package up LLVM or Clang
> for distribution has to compile and link shared against a version of
> curses, and the binary compatibility story becomes more complicated. Which
> version of curses do we use? is there a version that works on a wide range
> of linux distributions? etc etc.
> Previous dependencies such as libxml, zlib have had a graceful fallback. I
> don't see why this should be any different. Why kill the functionality of
> autodetecting without linking to an external library if it's cheap to keep?

I think libxml, zlib, and curses are no different here. They all provide
optional functionality. Without curses, we previously had bad behavior that
caused escape codes in places that couldn't handle them, and now have a
missing feature of color in a place we would like it. Without zlib, we have
a missing feature of compressed debug info in a place we would like it.

I don't think this complicates distribution. Note that we build dynamic
executables even though we link LLVM's libraries statically. So we already
depend on lots of shared libraries:

% ldd bin/clang
        linux-vdso.so.1 =>  (0x00007fff81dad000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f581ce56000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f581cc52000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f581c9fe000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f581c7e1000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f581c5cb000)
        libstdc++.so.6 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libstdc++.so.6 (0x00007f581c2c1000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f581c03f000)
        libgcc_s.so.1 =>
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libgcc_s.so.1 (0x00007f581be29000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f581baa0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f581d05f000)

I don't think anyone has had a problem with librt, libdl, libpthread, libz,
or libm, so I suspect adding libncurses won't cause anything to get worse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130807/727fd62c/attachment.html>

More information about the llvm-commits mailing list