[llvm-dev] Please dogfood LLD

[Khem Raj via llvm-dev]

On 3/19/17 12:10 PM, Ed Maste wrote:
> 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.

it is true for some other packages e.g. gnulib, gnuconfig to name a
couple, however, if we send a patch for libtool and point it on lld
website saying that please apply this patch to your libtool if you
reconfigure packages before building them. There were patches for gnulib
that originated from musl systems, it took a while for them to be come
downstream but eventually they do.

For distros, who do not reconfigure, we can send patches for patching
configure or .m4 scripts wherever these checks are made. Again pointing
users to the patches on lld website.

so far it seems there are only handful of packages, which seems
manageable IMO.

One advantage of having multiple tools is that packages becomes portable
and we find bugs in packages due to undue assumptions.
It should not be other way around.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170319/0f310ec5/attachment.sig>