Page MenuHomeFreeBSD

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

Authored by emaste on Sep 15 2018, 5:28 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Jan 17, 8:50 AM
Unknown Object (File)
Sat, Jan 17, 7:32 AM
Unknown Object (File)
Mon, Jan 12, 11:30 AM
Unknown Object (File)
Fri, Jan 9, 9:04 AM
Unknown Object (File)
Thu, Jan 8, 7:48 PM
Unknown Object (File)
Thu, Jan 8, 11:09 AM
Unknown Object (File)
Wed, Jan 7, 7:18 AM
Unknown Object (File)
Dec 12 2025, 8:26 PM
Subscribers

Details

Summary

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

Lint
Lint Skipped
Unit
Tests Skipped

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.