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:
ld -Bshareable -x -o libztcl1.0.4.so.0 init.o commands.o channel.o transform.o gzfile.o stream.o compress.o miscellaneous.o ztclStubInit.o -lz -L/usr/local/lib -ltclstub86
ld: error: unable to find library -lz
Known issues in this port or in lld that affect this port:
(2) lld has no built-in search paths (/lib, /usr/lib). Normally the linker is invoked from the compiler driver, and the search paths are added by the compiler. If lld is invoked directly library search paths must be specified explicitly, with -L/lib -L/usr/lib.
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.
Followup, if BINARY_ALIAS is used it should be in addition to LLD_UNSAFE, so that architectures without a /usr/bin/ld.bfd (arm64) work. If possible LLD_UNSAFE=yes should imply BINARY_ALIAS=ld=ld.bfd, under discussion on the ports mailing list.
A commit references this bug:
Date: Thu Mar 29 10:51:39 UTC 2018
New revision: 465883
Switch to ld.bfd by default as ld.ldd doesn't have built-in default
Submitted by: emaste
Approved by: portmgr (LLD_UNSAFE blanket)