On Wed, Mar 15, 2017 at 11:41 AM, Mark Kettenis via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Or perhaps we can cheat and include "GNU" somewhere in the > lld -v output ;).Let's please not do this. It would give the wrong signal. If libtool won't acknowledge lld's existence, then there are better ways like a rewrite and (temp) downstream patch.
On 15 March 2017 at 12:02, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On Wed, Mar 15, 2017 at 11:41 AM, Mark Kettenis via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >> Or perhaps we can cheat and include "GNU" somewhere in the >> lld -v output ;).This is the hack Rafael's been using for testing, adding "not GNU". libtool also looks for "supported targets: elf" in --help output. You can see the details of Rafael's hacks at http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161212/411904.html> Let's please not do this. It would give the wrong signal. > If libtool won't acknowledge lld's existence, then there > are better ways like a rewrite and (temp) downstream patch.Note that even if/when we get changes incorporated into libtool it will still take a long time for the change to appear in new releases of software packages using libtool. A downstream patch to the libtool package in various operating systems or distributions doesn't really help that much for the same reason. For the FreeBSD ports tree the most likely workaround would be some common sed magic to fix libtool's tests, along with a setting in (hundreds of) individual port Makefiles to apply it on a case-by-case basis.
On Wed, Mar 15, 2017 at 6:02 PM, Ed Maste <emaste at freebsd.org> wrote:> Note that even if/when we get changes incorporated into libtool it > will still take a long time for the change to appear in new releases > of software packages using libtool. A downstream patch to the libtool > package in various operating systems or distributions doesn't really > help that much for the same reason.AFAIU, systems where lld is the default ld are limited right now and can temporarily carry a minimally modified libtool. That way systems which have bfd or gold as default ld, which is most of the FOSS operating systems out there, won't notice any disturbance before, during or after libtool gets to know lld. I'm probably overlooking something but it looks like classical downstream integration patching due to the fact that it may take a while to get upstream or be rejected for non-technical reasons. What am I missing? I've been using ldd for building various code bases with autotools and libtool scripting, and must have been lucky to not run into the problem yet. I'll keep an eye out for libtool errors.> For the FreeBSD ports tree the most likely workaround would be some > common sed magic to fix libtool's tests, along with a setting in > (hundreds of) individual port Makefiles to apply it on a case-by-case > basis.If FreeBSD's libtool is patched to be aware of the base ld=lld, would this still be true?