linking ports with lld: some ports pass $LDFLAGS to $LD instead of the compiler driver

[Ed Maste]

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. One of the latter is described here.

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 $LDFLAGS ...),
when $LDFLAGS contains flags that are appropriate only for the
compiler driver, not the linker.

In several instances the flag comes from bsd.ssp.mk, which adds
-fstack-protector to LDFLAGS. GNU BFD ld accepts the flag but produces
undesired output (a bogus DT_AUXILIARY "stack-protector" entry):

% readelf -d /usr/local/lib/libcfg+.so.0

Dynamic section at offset 0x91a8 contains 15 entries:
  Tag                Type                  Name/Value
 0x000000007ffffffd AUXILIARY            Auxiliary library: [stack-protector]
...

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

This affects at least the following ports:
arabic/libitl
devel/libcfg
ftp/rexx-curl
www/dummyflash
www/mod_jk
www/tdom

I've submitted PRs for these ports and am happy to work with the
maintainers on a fix (both for our ports tree and to be submitted
upstream).