Bug 221809 - print/openprinting: fails to link with lld as system linker due to invalid -Mmapfile argument
Summary: print/openprinting: fails to link with lld as system linker due to invalid -M...
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: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks: 214864
  Show dependency treegraph
 
Reported: 2017-08-25 17:07 UTC by Ed Maste
Modified: 2018-04-05 02:45 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer freebsd_triage 2017-08-25 17:07:40 UTC
I've been investigating building the ports tree with LLVM's lld installed as /usr/bin/ld (via the exp-run in PR 214864). Through this I've found a few common issues, some of which are due to limitations of lld or choices made by its authors, and some of which are problems in the ports themselves. print/openprinting is affected by one of the latter cases.

When linking with lld the build failed with:

cc -shared  .libs/common.o .libs/uri.o .libs/list.o .libs/attribute.o .libs/status.o .libs/library.o .libs/misc.o  -L/usr/local/lib -lintl  -Wl,-Mmapfile -Wl,-soname -Wl,libpapi-common.so.0 -o .libs/libpapi-common.so.0.0.0
/usr/bin/ld: error: unknown argument: -Mmapfile

GNU ld documents -M as:
       -M
       --print-map
           Print a link map to the standard output.  A link map provides
           information about the link, including the following:

to write the mapping to a file the argument is:

       -Map mapfile
           Print a link map to the file mapfile.  See the description of the
           -M option, above.

so presumably this should be using -Wl,-Map,mapfile in $LDFLAGS

It appears that when GNU ld is invoked with -Mmapfile outputs the mapfile to stdout and discards the rest of the argument.
Comment 2 Ed Maste freebsd_committer freebsd_triage 2018-03-27 20:36:29 UTC
Via tobik@ in ports r465725, BINARY_ALIAS=ld=ld.bfd may be an effective workaround if LLD_UNSAFE does not work.
Comment 3 Ed Maste freebsd_committer freebsd_triage 2018-04-02 15:03:54 UTC
It looks like openprinting's ltmain.sh is too old to patch in -fuse-ld via
    -e 's/|-p|-pg|/|-B*|-fstack-protector*|-fuse-ld=*|-p|-pg|/'
(from Mk/Uses/libtool.mk)
Comment 4 Ed Maste freebsd_committer freebsd_triage 2018-04-05 01:49:20 UTC
Fix in https://reviews.freebsd.org/D14968
Comment 5 commit-hook freebsd_committer freebsd_triage 2018-04-05 02:43:31 UTC
A commit references this bug:

Author: emaste
Date: Thu Apr  5 02:43:08 UTC 2018
New revision: 466522
URL: https://svnweb.freebsd.org/changeset/ports/466522

Log:
  print/openprinting: fix build when lld is the system linker

  This port passes an invalid argument -Mmapfile to the linker.  Per GNU
  BFD ld's manpage, link map options are -M or --print-map to print a link
  map to stdout, or -Map mapfile to print a link map to mapfile.

  It appears that ld.bfd accepts -Mmapfile as a synonym for -M due to some
  quirk of its parser; lld simply fails with an unknown argument error.

  This port's embedded copy of libtool was also too old to know that it
  should pass the -fuse-ld flag from LDFLAGS through to the linker, and
  also too old to match the sed expression in Mk/Uses/libtool.mk that
  patches in knowledge of -fuse-ld.  Thus, patch ltmain.sh to add
  -fuse-ld=bfd as a passthrough flag.

  I do not know why libtool's authors believed that silently dropping
  flags from a user's provided LDFLAGS was (is) a sensible thing to do.

  PR:		221809
  Approved by:	ler
  Sponsored by:	The FreeBSD Foundation
  Differential Revision:	https://reviews.freebsd.org/D14968

Changes:
  head/print/openprinting/Makefile
  head/print/openprinting/files/patch-ltmain.sh
Comment 6 Ed Maste freebsd_committer freebsd_triage 2018-04-05 02:45:05 UTC
Summary updated to reflect that the lld failure prompted the PR, not the invalid argument per se.