The migration to the LLVM project's lld linker as the system linker (/usr/bin/ld) for FreeBSD is in progress - it is the case for arm64 and amd64 today, and i386 will switch once ports issues are addressed - see exp-run in PR214864. Linking archivers/p7zip with lld as /usr/bin/ld on i386 produces errors of the form: /usr/bin/ld: error: can't create dynamic relocation R_386_PC32 against symbol: memcpy in readonly segment; recompile object files with -fPIC >>> defined in /lib/libc.so.7 >>> referenced by 7zBuf2.c >>> 7zBuf2.o:(DynBuf_Write) http://package18.nyi.freebsd.org/data/headi386PR214864-default/2018-07-30_18h09m59s/logs/errors/p7zip-16.02_1.log
A commit references this bug: Author: mmokhi Date: Sun Aug 26 11:11:02 UTC 2018 New revision: 478120 URL: https://svnweb.freebsd.org/changeset/ports/478120 Log: archivers/p7zip: Fix build with lld as /usr/bin/ld on i386 PR: 230210 Reported by: emaste Reviewed by: mat, rakuco, tobik Approved by: rakuco (maintainer) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D16813 Changes: head/archivers/p7zip/Makefile
This bug looks like it may could be closed but looking at the Makefile why not have just CFLAGS=-fPIC instead of multiple CFLAGS_arch
(In reply to Nathan from comment #2) The reason I haven't closed it, was to wait for a feedback on MFH... About your point on different arches, I wanted to make my changes as smallest as possible so the maintainer takes less time for review and fix to land quicker... But also, personally I think having different arches with different flags (like what we have now) is better to have more control on different builds because the LLD thing is landing on different arches on different times I guess...
The intent is that on all architectures we will have either lld or use an out-of-tree toolchain (i.e., GNU BFD ld 2.17.50 will not be used anywhere), but this is for FreeBSD 13.0. Generally speaking if -fPIC fixes lld linking on i386 it's most likely a bug in the port, and it may be that it happens to work "by accident" on other architectures. That said, -fPIC can result in a small perf reduction, and should generally be applied only to libraries, so if the port's build infrastructure builds both binaries and libraries with the same CFLAGS then it might be applied more broadly than desired. As with mmokhi's comment I've tried to limit the scope of LLD workarounds to only those cases where we actually observed breakage, but if someone investigates a port failure and determines that the build should actually have -fPIC it's better to really fix it.
lld enabled as system linker for i386 on stable/12 in advance of 12.1
It looks like p7zip now builds without LDFLAGS_i386, presumably due to the addition of -fPIC. IMO the LDFLAGS_i386 can be removed.
I'm testing the port now.
A commit references this bug: Author: 0mp Date: Sat Oct 3 15:08:33 UTC 2020 New revision: 551317 URL: https://svnweb.freebsd.org/changeset/ports/551317 Log: Remove unnecessary LDFLAGS_i386 archivers/p7zip* ports build just fine without those flags. PR: 230210 Reported by: emaste Approved by: portmgr blanket Changes: head/archivers/p7zip/Makefile head/archivers/p7zip-codec-rar/Makefile