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. audio/oss is affected by one of the latter cases. 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. At one point in the build -fPIC is passed to ld, which is accepted by GNU BFD ld although it results in a bogus DT_AUXILIARY entry in the output: % readelf -d work/.build/target/lib/libossmix.so Dynamic section at offset 0x5000 contains 15 entries: Tag Type Name/Value 0x000000007ffffffd AUXILIARY Auxiliary library: [PIC] ... while lld produces an error: ld -shared -fPIC -o ../../target/lib/libossmix.so ./libossmix_cache.o ./libossmix_local.o ./libossmix_main.o ./libossmix_tcp.o ld: error: unknown argument: -fPIC
Via tobik@ in ports r465725, BINARY_ALIAS=ld=ld.bfd may be an effective workaround if LLD_UNSAFE does not work.
A commit references this bug: Author: emaste Date: Tue Mar 27 21:42:09 UTC 2018 New revision: 465763 URL: https://svnweb.freebsd.org/changeset/ports/465763 Log: audio/oss: set LLD_UNSAFE to link using ld.bfd This port fails when attempting to link with lld as the system linker. It passes -fPIC to the linker, which is actually a compiler flag. ld.bfd accepts the flag but it results in a bogus DT_AUXILIARY entry in the ouptut: Dynamic section at offset 0x5000 contains 15 entries: Tag Type Name/Value 0x000000007ffffffd AUXILIARY Auxiliary library: [PIC] PR: 221807 Approved by: portmgr (LLD_UNSAFE blanket) Sponsored by: The FreeBSD Foundation Changes: head/audio/oss/Makefile
Workaround committed