Color diagnostics

Hi,

I’m using the official 3.6 release binaries for x64 Linux. When compiling with warnings, I don’t see any color diagnostics. Explicitly enabling -fcolor-diagnostics works fine. I have TERM set to xterm-256color. Any idea why?

For what it’s worth, I tried compiling LLVM/clang from trunk and color diagnostics work fine by default.

Upon further investigation, I saw that the official binaries were not linked against libtinfo:

Official binaries:

[14:11:05] perry@meepo ~/test
zsh▸ ldd /home/perry/opt/clang+llvm-3.6.0-x86_64-linux-gnu/bin/clang
linux-vdso.so.1 => (0x00007fff7c5fe000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbda8a56000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbda8852000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbda854b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbda8247000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbda8031000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbda7c6b000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbda8c99000)

Built from trunk:
[14:11:19] perry@meepo ~/test
zsh▸ ldd ~/src/llvm-git/build/bin/clang
linux-vdso.so.1 => (0x00007fffa4ffe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f146879d000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f1468574000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1468355000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f146813c000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1467e38000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1467b31000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f146791b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1467556000)
/lib64/ld-linux-x86-64.so.2 (0x00007f14689c6000)

Is this a build issue or user error?

thanks,
-perry

+Chandler, who made the change
+Hans, who released the compiler

I’m really not sure what the right answer is here, though I don’t know that much about releasing software & dependencies (whether they can be made dynamically optional, etc)

Looks like the binaries weren’t built against tinfo correctly.

Looks like the binaries weren't built against tinfo correctly.

Should they be? Does that make a hard dependence on that? Is that what we
want for the published binaries & we just tell users it's a hard dependency
they have to install?

(Perhaps it's a trivial "yes" to all this - I just have no clue here)

Hi Perry,

I'm using the official 3.6 release binaries for x64 Linux. When compiling
with warnings, I don't see any color diagnostics. Explicitly enabling
-fcolor-diagnostics works fine. I have TERM set to xterm-256color. Any idea
why?

Which of the release binaries are you using? 3.6 has x86_64 binaries
for Ubuntu, OpenSuSE and Fedora, and they were built by difference
people.

From your ldd dump, it seems the binary you're using was built without

libtinfo, presumably because it wasn't installed on that machine and
we don't require it for building.

- Hans

Looks like the binaries weren't built against tinfo correctly.

Should they be? Does that make a hard dependence on that? Is that what we
want for the published binaries & we just tell users it's a hard dependency
they have to install?

(Perhaps it's a trivial "yes" to all this - I just have no clue here)

There's nothing in the script used for building releases
(utils/release/test-release.sh) that check for this, so I assume
libtinfo just wasn't installed on the machine on which the release was
built.

We should probably make the script check for it if it's a dependency
we want to enforce.

If the OS they’re targeting uses libtinfo, yes. If it just uses libncurses, it should link against that.

There are lots of distros and OSes which don’t need or want it? There are also users that don’t want it?

I think for packages being installed onto OSes which by default have these, the packages should by default use them. We’re talking about ncurses and tinfo, and so I think it’s a pretty mundane install requirement for debian or ubuntu systems. Similarly for fedora or redhat.

Hi Hans,

I used the official Ubuntu binary:
http://llvm.org/releases/3.6.0/clang+llvm-3.6.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz

Seems to me that it should be an optional dependency. If the target system has tinfo or ncurses, it should use it, otherwise fallback to no color.

Hi Hans,

I used the official Ubuntu binary:
http://llvm.org/releases/3.6.0/clang+llvm-3.6.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz

Seems to me that it should be an optional dependency. If the target system has tinfo or ncurses, it should use it, otherwise fallback to no color.

There is no reasonable way to implement that IMO. It would require using dlopen to test for the library, open up a world of security and performance concerns, etc.

There is no reasonable way to implement that IMO. It would require using
dlopen to test for the library, open up a world of security and performance
concerns, etc.

I understand. I also understand servers may not wish to have

ncurses/tinfo, and it may be an onerous hard dependency.

In any case, color diagnostics are advertised as default-on in the
documentation. It seems reasonable to expect that the release binaries
should reflect that.

Is this worth filing a bug?

In the meantime, I will bask in glorious color courtesy of trunk.

There is no reasonable way to implement that IMO. It would require using
dlopen to test for the library, open up a world of security and performance
concerns, etc.

I understand. I also understand servers may not wish to have ncurses/tinfo,
and it may be an onerous hard dependency.

In any case, color diagnostics are advertised as default-on in the
documentation. It seems reasonable to expect that the release binaries
should reflect that.

We could mandate that the release is built on machines with ncurses or
tinfo installed, to make sure this default works out-of-the box.

Is this worth filing a bug?

Yes, please.

In the meantime, I will bask in glorious color courtesy of trunk.

You could also build 3.6 from source, if you want the release version
specifically.

- Hans