Bug 224514 - devel/libtool: pass through -fuse-ld flags
Summary: devel/libtool: pass through -fuse-ld flags
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ed Maste
URL: https://reviews.freebsd.org/D13589
Keywords:
Depends on:
Blocks: 214864
  Show dependency treegraph
 
Reported: 2017-12-22 03:16 UTC by Ed Maste
Modified: 2017-12-27 02:19 UTC (History)
1 user (show)

See Also:
tijl: maintainer-feedback+


Attachments
patch to add -fuse-ld= to passed through options (1.90 KB, patch)
2017-12-22 03:16 UTC, Ed Maste
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2017-12-22 03:16:59 UTC
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.
Comment 1 Tijl Coosemans freebsd_committer 2017-12-22 12:07:25 UTC
(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.
Comment 2 Ed Maste freebsd_committer 2017-12-22 13:01:18 UTC
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.
Comment 3 Tijl Coosemans freebsd_committer 2017-12-22 14:12:23 UTC
(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.
Comment 4 Ed Maste freebsd_committer 2017-12-22 17:30:48 UTC
Thanks for the suggestion, change is in review D13589.
Comment 5 Ed Maste freebsd_committer 2017-12-22 17:33:26 UTC
> 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.
Comment 6 commit-hook freebsd_committer 2017-12-26 17:20:46 UTC
A commit references this bug:

Author: emaste
Date: Tue Dec 26 17:20:16 UTC 2017
New revision: 457295
URL: https://svnweb.freebsd.org/changeset/ports/457295

Log:
  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[1] 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.

  [1] http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=f9970d99293faf908fdc153a653fa5781095fb7a

  PR:		214864, 224514
  Reviewed by:	tijl
  Approved by:	portmgr (antoine)
  Sponsored by:	The FreeBSD Foundation
  Differential Revision:	https://reviews.freebsd.org/D13589

Changes:
  head/Mk/Uses/libtool.mk
Comment 7 Ed Maste freebsd_committer 2017-12-27 02:19:32 UTC
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.