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
signature.asc
Description: PGP signature
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
