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 multimedia/libx264 with lld fails with 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 mc.c >>> common/mc.o:(x264_plane_copy_c) /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 mc.c >>> common/mc.o:(x264_frame_init_lowres) /usr/bin/ld: error: can't create dynamic relocation R_386_PC32 against symbol: x264_frame_expand_border_lowres in readonly segment; recompile object files with -fPIC >>> defined in common/frame.o >>> referenced by mc.c >>> common/mc.o:(x264_frame_init_lowres) http://package18.nyi.freebsd.org/data/headi386PR214864-default/2018-07-30_18h09m59s/logs/errors/libx264-0.152.2854.log
I think this Makefile addition may work: .if ${ARCH} == i386 # PR230215 Allow relocations against read-only segments (override lld default) LDFLAGS+=-Wl,-z,notext .endif
(In reply to Ed Maste from comment #1) Thanks for the report Ed 1) Presumably this (LDFLAGS) should be scoped not only to arch, but also to FreeBSD version's (where lld is the default?) and/or compiler/linker in use (only clang?) 2) Is this a short term fix or workaround until lld adds support / fixes for something in the future? 3) If this is an lld/i386 specific issue, what is the context behind the required LDFLAGS not being a ports framework modification, rather than in specific ports? Is the fact that this is being addressed in the port, suggestive that there is a source/upstream specific issue ultimately here?
Quote from https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111875.html > lang/mono fails because lld defaults to -z text, disallowing > relocations in read-only segments (like .text). A workaround is to add > -z notext to the link command line, which turns off lld's error for > this case and results in the same behaviour as ld.bfd and ld.gold > provide by default.
bug 230208 apparently had the same issue (error), but this was addressed with LLD_UNSAFE=yes
> 1) Presumably this (LDFLAGS) should be scoped not only to arch, but also to > FreeBSD version's (where lld is the default?) and/or compiler/linker in use > (only clang?) It could be scoped to version, but it's not necessary: when GNU ld is used -znotext just reaffirms the default setting. > 2) Is this a short term fix or workaround until lld adds support / fixes for > something in the future? It's a workaround until the port can be fixed (either to avoid relocs against read-only segments) or for the upstream build infrastructure to take care of -znotext, assuming upstream wants to retain the RO segment relocs. > 3) If this is an lld/i386 specific issue It's not directly a lld/i386 issue; it's a combination of two things: - lld disallows RO segment relocations by default because they're generally an indication that the software being linked was built incorrectly - i386 has a large performance overhead from position-independent code
> bug 230208 apparently had the same issue (error), but this was addressed with > LLD_UNSAFE=yes Yeah, IMO this is a usable workaround, just punt on the issue and continue linking with GNU ld.
(In reply to Ed Maste from comment #6) Thank you for clarifying Ed. I'll defer to your analysis/expertise on the issue. Happy to approve any change you recommend (and attach here, or in a review), pending/contingent on QA passing (poudriere {10,11,12}-i386) to your satisfaction.
Created attachment 196348 [details] set LLD_UNSAFE on i386 and armv7 due to .text relocations
Comment on attachment 196348 [details] set LLD_UNSAFE on i386 and armv7 due to .text relocations Approved by: koobs (maintainer) MFH: 2018Q3
A commit references this bug: Author: emaste Date: Wed Sep 5 14:15:29 UTC 2018 New revision: 479024 URL: https://svnweb.freebsd.org/changeset/ports/479024 Log: multimedia/libx264: set LLD_UNSAFE for i386 and armv7 libx264 has relocations against readonly segment(s) and lld exits with an error suggesting recompiling with -fPIC. As this may introduce a performance impact, for now just fall back to GNU ld.bfd. PR: 230214 Approved by: koobs (maintainer) MFH: 2018Q3 Changes: head/multimedia/libx264/Makefile
A commit references this bug: Author: emaste Date: Wed Sep 5 14:48:13 UTC 2018 New revision: 479025 URL: https://svnweb.freebsd.org/changeset/ports/479025 Log: Revert r479024 due to build breakage PR: 230214 Changes: head/multimedia/libx264/Makefile
Adding : LDFLAGS= -Wl,-z,notext worked for me on 12-current i386
Comment on attachment 196348 [details] set LLD_UNSAFE on i386 and armv7 due to .text relocations Obsoleted by https://reviews.freebsd.org/D17201 (alternate method/solution)
A commit references this bug: Author: emaste Date: Tue Sep 18 14:00:45 UTC 2018 New revision: 480024 URL: https://svnweb.freebsd.org/changeset/ports/480024 Log: multimedia/libx264: add -znotext to LDFLAGS on i386, for lld Example error: /usr/bin/ld: error: can't create dynamic relocation R_386_PC32 against symbol: gettimeofday in readonly segment; recompile object files with -fPIC This port links some non-PIC code, which fails with lld as it defaults to disallowing relocations against read-only segments. For i386 we can just add -znotext unconditionally: for GNU BFD ld it just affirms BFD's existing default. PR: 214864, 230214 Reviewed by: koobs Approved by: koobs Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17201 Changes: head/multimedia/libx264/Makefile