Bug 221800 - www/mod_jk: port passes compiler-driver $LDFLAGS to linker invocation
Summary: www/mod_jk: port passes compiler-driver $LDFLAGS to linker invocation
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: Palle Girgensohn
Depends on:
Blocks: 214864
  Show dependency treegraph
Reported: 2017-08-25 12:56 UTC by Ed Maste
Modified: 2018-04-05 08:43 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (girgen)


Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2017-08-25 12:56:16 UTC
I've been investigating the state of the ports tree with LLVM's lld installed as /usr/bin/ld (from the exp-run in PR 214864).

Normally LDFLAGS contains flags passed to the compiler driver when invoked for linking. One issue that affects a small number of ports is passing $LDFLAGS to direct linker invocation (i.e, $LD), where it contains flags that are appropriate only for the compiler driver, not the linker.

In several instances this comes from bsd.ssp.mk, which adds -fstack-protector to LDFLAGS.  GNU BFD ld accepts the flag but produces undesired output, while lld produces an error:

ld -fstack-protector -shared -o libcfg+.so.0 ../src/cfg+.o ../src/parse.o ../src/props.o ../src/cmdline.o ../src/cfgfile.o ../src/shared.o ../src/platon/str/strplus.o ../src/platon/str/strctype.o ../src/platon/str/strdyn.o ../src/platon/str/dynfgets.o
ld: error: unknown argument: -fstack-protector
(from devel/libcfg)

(GNU ld produces output with a bogus DT_AUXILIARY "stack-protector" entry for this case.)

This affects at least the following ports:

www/mod_jk build log excerpt:
/usr/local/share/apr/build-1/libtool --silent --mode=link cc -I/usr/local/include/apache24 -O2 -pipe  -fstack-protector -fno-strict-aliasing -DHAVE_CONFIG_H -DUSE_APACHE_MD5 -I../common -I ../common  -O2 -pipe -I/usr/include -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing  -DHAVE_APR  -I/usr/local/include/apr-1 -I/usr/local/include/apr-1 -O2 -pipe  -fstack-protector -fno-strict-aliasing -DHAVE_CONFIG_H   -Wl,-L/usr/lib -Wl,-fstack-protector -Wl,-fstack-protector -o mod_jk.la -module -rpath /usr/local/libexec/apache24 -avoid-version mod_jk.lo ../common/jk_ajp12_worker.lo ../common/jk_connect.lo ../common/jk_msg_buff.lo ../common/jk_util.lo ../common/jk_ajp13.lo ../common/jk_pool.lo ../common/jk_worker.lo ../common/jk_ajp13_worker.lo ../common/jk_lb_worker.lo ../common/jk_sockbuf.lo ../common/jk_map.lo ../common/jk_uri_worker_map.lo ../common/jk_ajp14.lo ../common/jk_ajp14_worker.lo ../common/jk_md5.lo ../common/jk_shm.lo ../common/jk_ajp_common.lo ../common/jk_context.lo ../common/jk_url.lo ../common/jk_status.lo
/usr/bin/ld: error: unknown argument: -fstack-protector
/usr/bin/ld: error: unknown argument: -fstack-protector
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Comment 1 Ed Maste freebsd_committer 2017-08-25 13:03:46 UTC
Ah, in fact this port is not passing $LDFLAGS to a direct linker invocation, it's incorrectly wrapping compiler driver flags with -Wl, so that they get passed to the linker (but the end result is the same).
Comment 2 Walter Schwarzenfeld freebsd_triage 2018-01-16 15:45:26 UTC
Maintainer feedback, please!
Comment 3 Ed Maste freebsd_committer 2018-03-27 20:36:40 UTC
Via tobik@ in ports r465725, BINARY_ALIAS=ld=ld.bfd may be an effective workaround if LLD_UNSAFE does not work.
Comment 4 Kirill Ponomarev freebsd_committer 2018-04-01 12:52:44 UTC
You should add -fuse-ld=* into 2 ltmain.sh files in ${WRKSRC} to fix it. I would update the post to 1.2.43 as well. If you ENOTIME, let me know, so I can do it.
Comment 5 Ed Maste freebsd_committer 2018-04-02 14:54:35 UTC
patch-libtool in Mk/Uses/libtool.mk should add -fuse-ld=* to the passthrough arg list, maybe just adding libtool to USES is sufficient?
Comment 6 Palle Girgensohn freebsd_committer 2018-04-03 08:47:08 UTC

Is there any way I can make the port fail in this manner without the changing to LLVM? It seem from the discussion that the problem is not really in what the port does, but from stuff in Mk/*?

Please advise. :)

Comment 7 Kirill Ponomarev freebsd_committer 2018-04-03 09:00:38 UTC
(In reply to Palle Girgensohn from comment #6)
Yes, I suppose you're using poudriere, please do:

zfs rollback zroot/poudriere/jails/head-amd64@clean
ln -sf ld.lld /usr/local/poudriere/jails/head-amd64/usr/bin/ld
zfs destroy zroot/poudriere/jails/head-amd64@clean
zfs snapshot zroot/poudriere/jails/head-amd64@clean

krion% /usr/local/poudriere/jails/head-amd64/usr/bin/ld --version
LLD 6.0.0 (FreeBSD 326565) (compatible with GNU linkers)
Comment 8 Palle Girgensohn freebsd_committer 2018-04-03 16:13:10 UTC
I've tried a few permutations now, with the right ld installed, but I don't seem to get it working. Anyh tips?

I tried editing `scripts/build/unix/ltmain.sh` but I'm not that familiar with how ltmain.sh works anymore, it's been a while. Any tips appreciated. :)
Comment 9 Palle Girgensohn freebsd_committer 2018-04-03 16:15:49 UTC
also tried USES+= libtool to no avail
Comment 10 Ed Maste freebsd_committer 2018-04-05 02:49:33 UTC
I just fixed print/openprinting in r466522; I had to make ltmain.sh pass through the -fuse-ld flag. The issue there is that the libtool embedded in openprinting was just too old to match the sed expression in Mk/Uses/libtool.mk.
Comment 11 commit-hook freebsd_committer 2018-04-05 08:42:35 UTC
A commit references this bug:

Author: krion
Date: Thu Apr  5 08:42:24 UTC 2018
New revision: 466541
URL: https://svnweb.freebsd.org/changeset/ports/466541

  Fix build with ld.lld linker.
  Add LICENSE while I'm on it.

  PR:		221800
  Submitted by:	emaste
  Approved by:	portmgr (LLD_UNSAFE blanket)