On Thu, Aug 06, 2020 at 05:12:10PM -0700, PGNet Dev wrote: > i'm attempting to build a MaxMind GeopIP2 DB reader perl module > > MaxMind::DB::Reader::XS > > ( https://metacpan.org/pod/MaxMind::DB::Reader::XS > ) > > on Fedora 32. > > > the build fails on F32 with Errors: > > "/usr/bin/ld: unrecognized option '-Wl,-z,relro'" > '-Wl,-z,relro' is a linker flag. But not for /usr/bin/ld, but for /usr/bin/gcc. > I've filed a bug at the module upstream > > uninstallable on Fedora32, errors: "/usr/bin/ld: unrecognized option '-Wl,-z,relro'" & "Unsupported compile language "C"" ? > https://github.com/maxmind/MaxMind-DB-Reader-XS/issues/32 > > the build fails only with Fedora's distro perl, which _includes_ the ldflags > > perl -V | grep -i " ldflags" > ldflags ='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -L/usr/local/lib' > I think the build script does not use Perl configuration consistently. It uses ldflags value for the linker flags, but it does not use ld value for the linker exectable: $ perl -MConfig -E 'say $Config{ldflags}' -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -L/usr/local/lib $ perl -MConfig -E 'say $Config{ld}' gcc > but is _successful_ on opensuse, where distro perl's ldflags do NOT include '-Wl,-z,relro', > > perl -V | grep -i " ldflags" > ldflags =' -L/usr/local/lib64 -fstack-protector-strong' > If your /usr/bin/ld is the binutils ld, then -fstack-protector-strong is also an invalid option for ld (see ld manual page) and it should also fail. I think something tricks you. > Is this^ a problem with Fedora's perl build flags "incorrectly" _including_ > relro? Fedora mandates all packaged code to be built with relro. Therefore perl is also built with relro. > I've found/followed some of the perl hardening threads @ Fedora; > IIUC, it's intentional ... > It's not intentional, but it's how perl works. When you build perl, the linker flags are modified by a perl build script and built into the perl interpreter. Later when a third-party XS module is built, the built-in linker flags are reused. That's because the XS module must be binary compatible with the perl interpreter and having the same flags ensures it. (Some flags, especially compiler flags, changes ABI.) As a result, the third-party module is also built rerlo. We would like to change it, but perl build script is a giant mess. When I asked perl authors for explaining the mess, it turned out that they do not fully understand it and, more imporatantly, that they do not want to touch it all because they fear breaking a compatibility. > Or likely an issue with the module not correctly dealing with it? I think that's the case. It should use gcc program for linking. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
