[LLVMdev] Color diagnostics

[David Blaikie]

On Mon, Mar 30, 2015 at 2:47 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> 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)


>
> On Mon, Mar 30, 2015 at 2:30 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> +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)
>>
>> On Mon, Mar 30, 2015 at 11:16 AM, Perry Hung <perry at leaflabs.com> wrote:
>>
>>> 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 at 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 at 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
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150330/e0a0aa52/attachment.html>