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 devel/libcfg arabic/libitl www/tdom www/dummyflash ftp/rexx-curl 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)
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).
Maintainer feedback, please!
Via tobik@ in ports r465725, BINARY_ALIAS=ld=ld.bfd may be an effective workaround if LLD_UNSAFE does not work.
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.
patch-libtool in Mk/Uses/libtool.mk should add -fuse-ld=* to the passthrough arg list, maybe just adding libtool to USES is sufficient?
Hi! 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. :) Palle
(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)
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. :)
also tried USES+= libtool to no avail
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.
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 Log: Fix build with ld.lld linker. Add LICENSE while I'm on it. PR: 221800 Submitted by: emaste Approved by: portmgr (LLD_UNSAFE blanket) Changes: head/www/mod_jk/Makefile