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

James Molloy james at jamesmolloy.co.uk
Wed Aug 7 14:42:12 PDT 2013


The difference between zlib and curses is that the dependency on zlib was
added to support a *new feature*. Without it, you don't get the new
feature. Fair enough.

I think it's unreasonable to gate an already existing feature of the user
interface on a new dependency when there's no clear reason. OK, the old
algorithm was flaky and had a false positive. So if I, a user or packager,
care about that I can just now link against libcurses. Sorted.

So why remove the old fallback algorithm when those who care about the
false positive have a clear and obvious new workaround?

James



On 7 August 2013 22:32, Chandler Carruth <chandlerc at google.com> wrote:

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


More information about the llvm-commits mailing list