[RFC] hacking around libtool

[Rui Ueyama via llvm-commits]

I have a mixed feeling about this. This patch is undeniably convenient and
mitigate pain in migration, but if we add that string, libtool's
maintainers would lose the motivation to remove their hack from libtool. As
Ed wrote, this is exactly the web browser's user-agent situation.

Actually, the user-agent situation is a very  good analogy, because just
like billions of websites, we cannot ask everyone to fix their
hosts/development environments. We can fix FreeBSD's libtool, but that
won't fix the issue of other people who want to try LLD. If LLD doesn't
"just work" on the first try, they'll probably stop thinking LLD as a
serious alternative.

So I think I'm not really against adding this -- or even probably incline
to add it. It's just a one-line string in a "--help" message, right? That's
not a big deal, I guess.

But still, "LLD (not GNU)" is too funny.

On Tue, Dec 6, 2016 at 7:56 PM, Ed Maste <emaste at freebsd.org> wrote:

> On 6 December 2016 at 18:19, Rafael Avila de Espindola
> <rafael.espindola at gmail.com> wrote:
> >
> > Trying to build the freebsd ports I hit a failure because the php binary
> > was not built with --export-dynamic. It turns out the reason was libtool
> > looking at the output of -v and --help to decide if it should use
> > --export-dynamic or not.
>
> In FreeBSD we had exactly that same kind of problem with libtool and
> ELF Tool Chain's strip (https://savannah.gnu.org/patch/?8675,
> https://bugs.freebsd.org/198611).
>
> We'll want to get a patch to detect LLD into libtool, but
> unfortunately it's a rather slow moving project (it took 9 months to
> get the ELF Tool Chain patch committed). If we have a proposed patch
> though it can be added to the FreeBSD libtool port. At least the
> problem will be solved in FreeBSD while waiting for it to be committed
> upstream.
>
> Of course there's also long latency before the updated libtool
> percolates into downstream software, but we can have the ports
> infrastructure patch the existing instances.
>
> > I have coded the attached patch to work around the problem, but it is
> > probably too disgusting to have it in tree.
>
> I had joked about making the strip version output "strip (elftoolchain
> r3136M (like GNU strip))". But I agree it's a terrible (albeit useful)
> hack. I think we can propose a decent patch to libtool, and if you
> don't have a chance to take a look I will after conference travel +
> holidays.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161206/066d7caf/attachment.html>