Created attachment 189026 [details]
patch to add -fuse-ld= to passed through options
Some ports depend on permissive or broken behaviour from the GNU BFD linker, ld.bfd. Clang and GCC support a -fuse-ld= flag to specify the linker to use, and as we migrate to installing lld as the base system's /usr/bin/ld we'll want to make use of -fuse-ld=bfd to let ports that fail with lld use bfd instead.
An upstream libtool change from Feb 2016 supports passing through -fuse-ld=, but it has not yet made it into a release: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=f9970d99293faf908fdc153a653fa5781095fb7a
This is an equivalent change for our libtool port.
(In reply to Ed Maste from comment #0)
I suspect you have to patch Mk/Uses/libtool.mk instead of devel/libtool. Very few ports use libtool from devel/libtool.
You can add -fuse-ld=* right after -fstack-protector* on line 68 in Mk/Uses/libtool.mk.
I've been working through the list of ports failing when linked by lld sorted by number of transitive skipped ports, and lang/mono is near the top of that list. It seems mono uses devel/libtool's ltmain.sh via libtoolize and mono built with this patch applied and LLD_UNSAFE=yes in mono's Makefile.
Is the intent that a change in Mk/Uses/libtool.mk would also be applied against the new ltmain.sh copied from devel/libtool for ports that use it? Even if that's the case I think we'd want both patches - I'd like to be able to build 3rd party software that uses libtool outside of the ports infrastructure.
(In reply to Ed Maste from comment #2)
Yes, USES=libtool makes its changes after libtoolize (which runs as part of USES=autoreconf). You want to patch Mk/Uses/libtool.mk for ports that don't have USES=autoreconf.
You only need to patch devel/libtool if you run libtoolize (autoreconf) outside the ports tree and then only if you also run configure+make outside the ports tree and if the software needs to be built with -fuse-ld. If that's the case though then feel free to commit your patch.
Thanks for the suggestion, change is in review D13589.
> You only need to patch devel/libtool if you run libtoolize (autoreconf) outside
> the ports tree and then only if you also run configure+make outside the ports
> tree and if the software needs to be built with -fuse-ld. If that's the case
> though then feel free to commit your patch.
Indeed, that will be the case for me, at least during this development - I'll be using libtool from ports, and want to run configure + make in an upstream repo, both with and without -fuse-ld, while trying to produce a patch appropriate for upstream.
A commit references this bug:
Date: Tue Dec 26 17:20:16 UTC 2017
New revision: 457295
libtool.mk: pass through LDFLAGS -fuse-ld=*
Some ports depend on permissive or broken behaviour from the GNU BFD
linker, ld.bfd. Clang and GCC support a -fuse-ld= flag to choose a
specific linker, and as we migrate to installing lld as the base system
/usr/bin/ld we'll want to make use of -fuse-ld=bfd to use bfd for ports
that fail to link, or fail to run when linked with lld.
An upstream libtool change from Feb 2016 supports passing through
-fuse-ld=, but it has not yet made it into a release. Patch an
equivalent change into ltmain.sh via Mk/Uses/libtool.mk.
Original proposal just patched ltmain.sh in devel/libtool. That would
address ports that run libtoolize via autoreconf, including lang/mono
which is one of the ports that fails to link with lld and responsible
for many downstream skipped ports. Patching ltmain.sh via libtool.mk
(tijl's suggestion) handles that case as well as ports that include
their own copy of ltmain.sh.
A later change may patch devel/libtool so that -fuse-ld works if using a
ports-installed libtool to build software outside of the ports tree; the
change in this commit is intended to address building in the ports tree.
PR: 214864, 224514
Reviewed by: tijl
Approved by: portmgr (antoine)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13589
tijl's suggestion now committed to Mk/Uses/libtool.mk and this should be good for the ports tree. For developing 3rd party software we're probably better served by trying to encourage libtool upstream to do another release, and/or using a libtool snapshot with the change included.