I'm working on switching to LLVM's lld linker as the FreeBSD system linker (/usr/bin/ld), and the port in this PR is reported as a new failure in the exp-run, PR 214864.
An excerpt from the build log:
cd /wrkdirs/usr/ports/net-p2p/monero-cli/work/monero-0.11.1.0/src/blocks && cd /wrkdirs/usr/ports/net-p2p/monero-cli/work/monero-0.11.1.0/src/blocks && /usr/bin/ld -r -b binary -o /wrkdirs/usr/ports/net-p2p/monero-cli/work/monero-0.11.1.0/src/blocks/blocks.o blocks.dat
/usr/bin/ld: error: target emulation unknown: -m or at least one .o file required
ninja: build stopped: subcommand failed.
Known issues in this port or in lld that affect this port:
(4) lld does not have a built-in default output target. For the most common use of the linker (linking individual .o objects into an executable or shared object) lld infers the target from the first object file. However, when the linker is used to convert an arbitrary binary file into an ELF object (via -r -b binary) lld must have the output target specified explicitly with -m.
FreeBSD 11 and later have lld available as /usr/bin/ld.lld, so one simple option for testing is to just symlink /usr/bin/ld to ld.lld (and restore it to ld.bfd).
A port Makefile knob, LLD_UNSAFE=yes, exists to indicate that a port does not work with lld, and requires either /usr/bin/ld.bfd or binutils from ports. This should work for the common case of ports written in C using GNU autoconf; it may have no effect on other ports.
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:
Date: Wed Mar 28 13:49:26 UTC 2018
New revision: 465811
Switch to ld.bfd by default as ld.ldd doesn't have built-in default
Submitted by: emaste
Approved by: portmgr (LLD_UNSAFE blanket)
Reopen as net-p2p/monero-cli fails to build even with LLD_UNSAFE
Closing this as it has been fixed with the latest changes in the port (c471906).
(In reply to Vasil Dimov from comment #4)