Page MenuHomeFreeBSD

multimedia/openh264: add -znotext to LDFLAGS on i386, for lld

Authored by emaste on Sep 15 2018, 5:28 PM.
Referenced Files
Unknown Object (File)
Sun, May 28, 10:09 AM
Unknown Object (File)
May 3 2023, 6:27 PM
Unknown Object (File)
Mar 16 2023, 10:15 PM
Unknown Object (File)
Feb 28 2023, 5:26 PM
Unknown Object (File)
Feb 19 2023, 12:49 AM
Unknown Object (File)
Feb 17 2023, 4:23 AM
Unknown Object (File)
Feb 11 2023, 7:17 PM
Unknown Object (File)
Feb 4 2023, 7:45 PM



Example error:

/usr/bin/ld: error: can't create dynamic relocation R_386_32 against local symbol 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.

I am not a ports committer, so please explicitly mention approval for commit to the ports tree.

Diff Detail

rP FreeBSD ports repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

Don't we need -fPIC for this port's i386 build as well?

Don't we need -fPIC for this port's i386 build as well?

We don't need -fPIC - it builds successfully with just -znotext. My primary goal here is just to have lld linking things as ld.bfd did. Using -fPIC might be more correct in the long term but I would rather have port maintainers investigate that change and determine if there's a reason why certain ports are not being built with -fPIC. For i386 there may have been an explicit decision to avoid -fPIC due to the relatively larger performance impact on i386 vs other architectures.

In general if we add -fPIC we should not need -znotext, unless the port also has some non-PIC assembly or does not pass the -fPIC into all compile invocations.

This revision was not accepted when it landed; it landed in state Needs Review.Sep 18 2018, 4:07 PM
This revision was automatically updated to reflect the committed changes.