On Thu, Mar 16, 2017 at 11:26 AM, Ed Maste via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 15 March 2017 at 16:34, Carsten Mattner <carstenmattner at gmail.com> > wrote: > > > > If FreeBSD's libtool is patched to be aware of the base ld=lld, > > would this still be true? > > Yes, for the same reason Joerg points out in another reply in this > thread - some software packages are going to include in their > configure scripts parts of whatever libtool version existed on the > machine used by a developer to produce a release. >It looks like we've picked up Phoronix's attention: http://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=3 Note that they did this test in the most brutal possible way (replacing /usr/bin/ld with LLD). It seems that they found that a few packages failed to build with LLD. I tried reproducing the libjpeg-turbo one and it seems likely to be due to differences in configure. This is the diff: https://reviews.llvm.org/P7977 I can't repro the libjpeg-turbo failure configuring with a plain -fuse-ld=lld (using clang as CC, and with /usr/bin/ld as ld.bfd). It seems that the configure scripts actually call directly into /usr/bin/ld for this check or something similarly nasty (which is pretty suspect, since it defeats whatever linker feature is being tested when it invokes the linker "for real" through CC `). Adding "not GNU" into the version string seems to allow libjpeg-turbo to build (though it still detects shared libraries aren't available, and adding `: supported targets: elf` in --help seems to get shared libraries back). With those two hacks (patch attached), I see the following configure diff which seems benign: https://reviews.llvm.org/P7978 See the thread "lld status on the freebsd ports" where Rafael shared his findings from the freebsd ports, inclusing these hacks. I think we should seriously consider adding these hacks (possibly in a way that more clearly highlights to users why we had to put them in, such as "the following lines are for libtool < vX.Y:"). Realistically, even if we land a fix in upstream libtool today, we are unlikely to be able to really rely on that in the wild for perhaps 5 years. I don't think our users should have to wait that long for LLD to "Just Work" for them. We want LLD to have as little "fine print" as possible. It looks like "stockfish" and "TTSIOD" also failed to link as well. Stockfish seems to fail because by default when compiling with GCC the makefile uses -flto and LLD doesn't understand the GCC IR files. I think the COFF linker handles this by shelling out to the system linker in the case of MSVC LTO, and ELF should probably do the same. I haven't looked into TTSIOD. This seems to have caused some bad publicity: https://www.reddit.com/r/programming/comments/601kn9/trying_out_llvm_40s_lld_linker/ One user even comes away with this impression: "As you can see in the link, LLD is unable to link several projects. It's far from production ready." (and I cannot blame them; LLD should "Just Work" with almost all major open-source software packages, and failing 3, including a very common one like libjpeg-turbo which is used by firefox and chromium, doesn't reflect well) One user experiencing a segfault appears to have been kind enough to send us a bug report: https://bugs.llvm.org/show_bug.cgi?id=32341 -- Sean Silva> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170318/d918efbf/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: phonybfd.patch Type: text/x-patch Size: 926 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170318/d918efbf/attachment.bin>
On 19 March 2017 at 01:06, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:> This seems to have caused some bad publicity: > https://www.reddit.com/r/programming/comments/601kn9/trying_out_llvm_40s_lld_linker/ > One user even comes away with this impression: "As you can see in the link, > LLD is unable to link several projects. It's far from production ready." > (and I cannot blame them; LLD should "Just Work" with almost all major > open-source software packages, and failing 3, including a very common one > like libjpeg-turbo which is used by firefox and chromium, doesn't reflect > well)Hi Sean, You can't avoid bad publicity, even if you do everything right. It took Rui almost a year more than it took me to think LLD was good enough for wider use, and it still wasn't. Do you know why? Because it never will. Toolchain development is a curse as much as it's an bless. You can do some amazing software and still be caught with your pants down on really simple cases. Different than almost every other software technology on the planet (modulo kernel), toolchains have to cope with a problem space that is so random, unpredictable and crazy, that it's literally impossible to compile every software on the planet. It just is. However, most non-toolchain / non-kernel developers will look at their new shiny tool, which claims "production use" and will think: "Oh, this *must* work on all the crazy things I've done in the past". Most of us know this is non-sense and we shouldn't be deterred by comments like this. They're noise, not signal. The Phoronix article hints at something inspiring: All workloads were faster, and some were significantly faster. "Can't compile", as we know, can be a simple bug, user error, unsupported GNU extensions, lack of tests on that specific platform, etc. They should be fixed, yes, but they're not a reflection of your work, let alone "the only" reflection. Maybe one lesson we can learn from this is: don't use the words "production ready", but instead "user beta testing". It worked very well for Google for the past 10 years and can work for us, too. :)> One user experiencing a segfault appears to have been kind enough to send us > a bug report: https://bugs.llvm.org/show_bug.cgi?id=32341Most users are nice. So far, there was only one negative comment... Noise, in my view. The LLD developers are, in my view, doing an amazing job. Please, don't be affected by noise. cheers, --renato
On Sat, Mar 18, 2017 at 6:07 PM Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Thu, Mar 16, 2017 at 11:26 AM, Ed Maste via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On 15 March 2017 at 16:34, Carsten Mattner <carstenmattner at gmail.com> > wrote: > > > > If FreeBSD's libtool is patched to be aware of the base ld=lld, > > would this still be true? > > Yes, for the same reason Joerg points out in another reply in this > thread - some software packages are going to include in their > configure scripts parts of whatever libtool version existed on the > machine used by a developer to produce a release. > > > > It looks like we've picked up Phoronix's attention: > http://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=3 > Note that they did this test in the most brutal possible way (replacing > /usr/bin/ld with LLD). > > It seems that they found that a few packages failed to build with LLD. > > I tried reproducing the libjpeg-turbo one and it seems likely to be due to > differences in configure. This is the diff: https://reviews.llvm.org/P7977 > > I can't repro the libjpeg-turbo failure configuring with a plain > -fuse-ld=lld (using clang as CC, and with /usr/bin/ld as ld.bfd). It seems > that the configure scripts actually call directly into /usr/bin/ld for this > check or something similarly nasty (which is pretty suspect, since it > defeats whatever linker feature is being tested when it invokes the linker > "for real" through CC `). > > Adding "not GNU" into the version string seems to allow libjpeg-turbo to > build (though it still detects shared libraries aren't available, and > adding `: supported targets: elf` in --help seems to get shared libraries > back). With those two hacks (patch attached), I see the following configure > diff which seems benign: https://reviews.llvm.org/P7978 > See the thread "lld status on the freebsd ports" where Rafael shared his > findings from the freebsd ports, inclusing these hacks. > > I think we should seriously consider adding these hacks (possibly in a way > that more clearly highlights to users why we had to put them in, such as > "the following lines are for libtool < vX.Y:"). Realistically, even if we > land a fix in upstream libtool today, we are unlikely to be able to really > rely on that in the wild for perhaps 5 years. I don't think our users > should have to wait that long for LLD to "Just Work" for them. We want LLD > to have as little "fine print" as possible > . >perhaps its better to provide fixes to these applications to not look for tool specific strings. If you put such knobs into tools then you have to live with it for life of the tool. musl libc had similar problems where it exposed assumptions about libc specific implementation, musl's adherence to not mimic the behavior ended up in cleaning up many of the packages and making them more portable. Problems you are describing seems to be also in similar realm, I would rather suggest to provide fixes for the packages instead of fixing lld.> > >> > It looks like "stockfish" and "TTSIOD" also failed to link as well. > Stockfish seems to fail because by default when compiling with GCC the > makefile uses -flto and LLD doesn't understand the GCC IR files. I think > the COFF linker handles this by shelling out to the system linker in the > case of MSVC LTO, and ELF should probably do the same. > I haven't looked into TTSIOD. > > This seems to have caused some bad publicity: https://www.reddit. > com/r/programming/comments/601kn9/trying_out_llvm_40s_lld_linker/ > One user even comes away with this impression: "As you can see in the > link, LLD is unable to link several projects. It's far from production > ready." > (and I cannot blame them; LLD should "Just Work" with almost all major > open-source software packages, and failing 3, including a very common one > like libjpeg-turbo which is used by firefox and chromium, doesn't reflect > well) > One user experiencing a segfault appears to have been kind enough to send > us a bug report: https://bugs.llvm.org/show_bug.cgi?id=32341 > > -- Sean Silva > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170319/1164acf7/attachment.html>
On 19 March 2017 at 18:30, Khem Raj via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Problems you are describing seems to be also in similar realm, I would > rather suggest to provide fixes for the packages instead of fixing lld.+1000! Clang has managed to clear up thousands of user bugs throughout the years. It'd be cool if LLD could do the same. --renato
On 19 March 2017 at 14:30, Khem Raj <raj.khem at gmail.com> wrote:> > perhaps its better to provide fixes to these applications to not look for > tool specific strings. If you put such knobs into tools then you have to > live with it for life of the tool. musl libc had similar problems where it > exposed assumptions about libc specific implementation, musl's adherence to > not mimic the behavior ended up in cleaning up many of the packages and > making them more portable.Yes, libtool is absolutely the proper place for this issue to be fixed. That's tricky for two reasons: 1. Libtool's upstream is not responsive, so I don't anticipate this being fixed soon. It took about a year to get a patch incorporated to accept ELF Tool Chain's strip instead of GNU strip. Even then it limits the check to FreeBSD, so ELF Tool Chain users on other platforms are out of luck. 2. Parts of libtool end up embedded in the configure script of libtool-using third party software, so even once a fix is incorporated into libtool it will take quite some time for it to appear in new versions of arbitrary software. In FreeBSD I expect that we'll patch the libtool package ourselves as a workaround, and also incorporate a workaround in the ports tree to apply the same patch to each libtool-using package.
On Sat, Mar 18, 2017 at 9:06 PM, Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I think we should seriously consider adding these hacks (possibly in a way > that more clearly highlights to users why we had to put them in, such as > "the following lines are for libtool < vX.Y:"). Realistically, even if we > land a fix in upstream libtool today, we are unlikely to be able to really > rely on that in the wild for perhaps 5 years. I don't think our users > should have to wait that long for LLD to "Just Work" for them. We want LLD > to have as little "fine print" as possible. >I agree. There is really nothing to be gained by forcing everyone to regenerate their "configure" scripts. Having "lld -v" print something like "For libtool's benefit: GNU" at the end of the output is a **very** small price to pay to avoid years of incompatibility with configure scripts which haven't been generated with a not-even-released-yet version of libtool. For the second half of the issue, I'd say that having "lld --help" print what it supports actually seems a sensible thing to do in any case! Might as well just have it *actually* print out its supported list of targets and emulations. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170319/61d5c754/attachment.html>
I didn't mean what I said in a negative way. I think it just very plainly shows a user's perspective. We already know about the issues in my email (the libtool hack and that LLD is currently incompatible with GCC LTO). We know how to fix them too. But we didn't know exactly how problematic they are when tested in a relatively black-box fashion. The way that Phoronix tested this is the most brutal possible way (replace /usr/bin/ld with LLD, and then a simple yes/no "does it work" on various software packages), but that is the bar that we want to get to, and this is a piece of information pointing us towards where we want to go. -- Sean Silva On Sun, Mar 19, 2017 at 4:53 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 19 March 2017 at 01:06, Sean Silva via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > This seems to have caused some bad publicity: > > https://www.reddit.com/r/programming/comments/601kn9/ > trying_out_llvm_40s_lld_linker/ > > One user even comes away with this impression: "As you can see in the > link, > > LLD is unable to link several projects. It's far from production ready." > > (and I cannot blame them; LLD should "Just Work" with almost all major > > open-source software packages, and failing 3, including a very common one > > like libjpeg-turbo which is used by firefox and chromium, doesn't reflect > > well) > > Hi Sean, > > You can't avoid bad publicity, even if you do everything right. It > took Rui almost a year more than it took me to think LLD was good > enough for wider use, and it still wasn't. > > Do you know why? Because it never will. > > Toolchain development is a curse as much as it's an bless. You can do > some amazing software and still be caught with your pants down on > really simple cases. Different than almost every other software > technology on the planet (modulo kernel), toolchains have to cope with > a problem space that is so random, unpredictable and crazy, that it's > literally impossible to compile every software on the planet. It just > is. > > However, most non-toolchain / non-kernel developers will look at their > new shiny tool, which claims "production use" and will think: "Oh, > this *must* work on all the crazy things I've done in the past". Most > of us know this is non-sense and we shouldn't be deterred by comments > like this. They're noise, not signal. > > The Phoronix article hints at something inspiring: All workloads were > faster, and some were significantly faster. "Can't compile", as we > know, can be a simple bug, user error, unsupported GNU extensions, > lack of tests on that specific platform, etc. They should be fixed, > yes, but they're not a reflection of your work, let alone "the only" > reflection. > > Maybe one lesson we can learn from this is: don't use the words > "production ready", but instead "user beta testing". It worked very > well for Google for the past 10 years and can work for us, too. :) > > > > One user experiencing a segfault appears to have been kind enough to > send us > > a bug report: https://bugs.llvm.org/show_bug.cgi?id=32341 > > Most users are nice. So far, there was only one negative comment... > Noise, in my view. > > The LLD developers are, in my view, doing an amazing job. Please, > don't be affected by noise. > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170320/9ffa23bb/attachment.html>
On Sat, Mar 18, 2017 at 9:06 PM, Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > It looks like "stockfish" and "TTSIOD" also failed to link as well. > Stockfish seems to fail because by default when compiling with GCC the > makefile uses -flto and LLD doesn't understand the GCC IR files. I think > the COFF linker handles this by shelling out to the system linker in the > case of MSVC LTO, and ELF should probably do the same. > I haven't looked into TTSIOD. >I suggest that the correct behavior in the case of encountering foreign LTO files is to print an error message such as "Encountered foreign LTO files. When using LLVM LLD with LTO, object files must be in the LLVM bitcode format, usually produced by clang. To solve this choose an option: 1. Use clang to produce the object files 2. Use a linker compatible with the object files (probably the system linker) 3. Disable LTO." Ultimately I think that printing an error message such as this and exiting would result in less user confusion than shelling out to the system linker. If the phoronix person doing this test had seen this, they might have tried to follow one of those 3 steps instead of concluding that LLD was broken. If we do end up going with the shelling out approach, I as an upstream user would appreciate if there was a flag to disable this feature, and make it an error if it had to shell out. I am using LLD to intentionally not depend on the system linker, and if LLD shells out to the system linker then it thwarts this goal. Also, this shelling out approach only works on the native platform and not for cross compiling. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170321/a32be45b/attachment.html>
On Tuesday, March 21, 2017, Andrew Kelley <superjoe30 at gmail.com> wrote:> On Sat, Mar 18, 2017 at 9:06 PM, Sean Silva via llvm-dev < > llvm-dev at lists.llvm.org > <javascript:_e(%7B%7D,'cvml','llvm-dev at lists.llvm.org');>> wrote: >> >> It looks like "stockfish" and "TTSIOD" also failed to link as well. >> Stockfish seems to fail because by default when compiling with GCC the >> makefile uses -flto and LLD doesn't understand the GCC IR files. I think >> the COFF linker handles this by shelling out to the system linker in the >> case of MSVC LTO, and ELF should probably do the same. >> I haven't looked into TTSIOD. >> > > I suggest that the correct behavior in the case of encountering foreign > LTO files is to print an error message such as "Encountered foreign LTO > files. When using LLVM LLD with LTO, object files must be in the LLVM > bitcode format, usually produced by clang. To solve this choose an option: > 1. Use clang to produce the object files 2. Use a linker compatible with > the object files (probably the system linker) 3. Disable LTO." > > Ultimately I think that printing an error message such as this and exiting > would result in less user confusion than shelling out to the system linker. > If the phoronix person doing this test had seen this, they might have tried > to follow one of those 3 steps instead of concluding that LLD was broken. > > If we do end up going with the shelling out approach, I as an upstream > user would appreciate if there was a flag to disable this feature, and make > it an error if it had to shell out. I am using LLD to intentionally not > depend on the system linker, and if LLD shells out to the system linker > then it thwarts this goal. >Yeah. I think for LLD/COFF shelling out to the system linker is an opt-in. -- Sean Silva> > Also, this shelling out approach only works on the native platform and not > for cross compiling. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170321/8021d27e/attachment.html>