Looks like the binaries weren't built against tinfo correctly. 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/0c215721/attachment.html>
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>
On Mon, Mar 30, 2015 at 2:52 PM, David Blaikie <dblaikie at gmail.com> wrote:> > > 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)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.>> 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 > >
On Mon, Mar 30, 2015 at 5:58 PM David Blaikie <dblaikie at gmail.com> wrote:> 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? >If the OS they're targeting uses libtinfo, yes. If it just uses libncurses, it should link against that.> Does that make a hard dependence on that? >There are lots of distros and OSes which don't need or want it? There are also users that don't want it?> Is that what we want for the published binaries & we just tell users it's > a hard dependency they have to install? >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.> > (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 >>> >> _______________________________________________ > 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/51bed8ef/attachment.html>