Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1242817
Summary: | postgresql-9.4.4-2.fc23 FTBFS: configure: error: libperl library is required for Perl | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Petr Pisar <ppisar> |
Component: | postgresql | Assignee: | Pavel Raiskup <praiskup> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | devrim, hhorak, jstanek, pbrobinson, praiskup, tgl |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | http://koji.fedoraproject.org/koji/taskinfo?taskID=10340701 | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-10-15 16:35:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Petr Pisar
2015-07-14 08:38:32 UTC
Thanks for the report. From PGAC_CHECK_PERL_EMBED_LDFLAGS macro: $ perl -MConfig -e 'print $Config{ccdlflags}, "\n"' -Wl,--enable-new-dtags -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld This is used as value for "$perl_embed_ldflags". Then the configure check uses it like: $ gcc main.c -I/usr/lib64/perl5/CORE -lperl -Wl,--enable-new-dtags -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld /bin/ld: /tmp/cc3ouPG1.o: relocation R_X86_64_32 against `PL_memory_wrap' can not be used when making a shared object; recompile with -fPIC /tmp/cc3ouPG1.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Side note while we are on it, should not we use the 'lddlflags' instead of 'ccldflags' there? The $perl_embed_ldflags variable is used in: # SHLIB_LINK If shared library relies on other libraries, # additional stuff to put in its link command The Config's identifiers are confusing (at least for me). See "perldoc Config" for their listing and description. Your command is used to compile and to link. So you need use two values. One for compiling (to have -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1), one for linking (to have -specs=/usr/lib/rpm/redhat/redhat-hardened-ld). Exact identifiers depends on what you want to get: executable or DSO? I believe you want an executable. Then think you should use ccflags and ccdlflags. This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 Sorry, I did wrong analysis before. (In reply to Petr Pisar from comment #0) > postgresql-9.4.4-2.fc23 fails to build in F23: > > checking for perl.h... yes > checking for libperl... no > configure: error: libperl library is required for Perl > [...] > perl-4:5.22.0-347.fc23 started to propagate Fedora's compiler and linker > flags properly, so this failure could be caused by an incompatible flags > applied by this package. What is actually done during ./configure --enable-perl is something like: $ cat main.c #include <EXTERN.h> #include <perl.h> int main () { perl_alloc(); ; return 0; } $ gcc main.c -I/usr/lib64/perl5/CORE `perl -MExtUtils::Embed -e ldopts` /bin/ld: /tmp/ccSLCm30.o: relocation R_X86_64_32 against `PL_memory_wrap' can not be used when making a shared object; recompile with -fPIC /tmp/ccSLCm30.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status From 'perldoc ExtUtils::Embed': ldopts() Output arguments for linking the Perl library and extensions to your application. It really looks like the perl installation is broken, Petr can you confirm/fix my assumptions? > I think relevant postgresql's bug report is bug #947022. This does not seem to be related. I've tried to "not undefine" %_hardened_build in spec file and the FTBFS still occurred. Pavel ldopts() are only linker flags. You are missing the compiler flags which will provide -fPIC. Maybe you don't understand the PIE hardening. To get PIE executable you have to compile objects with -fPIC and link an executable from them with -pie. You have to do both of them. Not only the first or second thing. The ExtUtils::Embed starts with this triplet: perl -MExtUtils::Embed -e xsinit perl -MExtUtils::Embed -e ccopts perl -MExtUtils::Embed -e ldopts You need the ccopts value whan invoking "gcc -c", and ldopts value when invoking "ld". Ok, thus 'perl -MExtUtils::Embed -e ccopts' should play some role here too. I'll try to look at possible upstream patch. But this is not very nice for downstream packaging as we still do "%undefine _hardened_build" and I'm not sure when we will be able to avoid that (at least for 32bit arches). So this will be a bit inconsistent because (in contrast with rest postgresql package), perl parts will be hardened. I can hack the hardenig flags out of course but that is also not very nice. Does anybody have an opinion? I'm not completely convinced that this "enforced hardening" decided by perl installation is right approach. The main problem is that there is no easy way to disable hardening (or at least I don't see it). Please go to the perl upstream and tell them it. They claim that building perl applications with different options than the perl is bad and unsupported. And this attitude goes through all Perl build systems. If we removed it we would broke all the other users' expectations. Perl does not have anything like "build me with foo but tell the other ones to use bar". But we also started to notice failures in some Perl packages after hardening (bug #1238804). So we will probably disable the hardening until finding a real fix. For you information, I disabled hardening in perl-5.22.0-349. Fedora 24+ has hardened PostgreSQL: http://pkgs.fedoraproject.org/cgit/postgresql.git/commit/?id=72ca6afc2a7d65 Perl is hardened in Fedora again since: http://pkgs.fedoraproject.org/cgit/rpms/perl.git/commit/?id=59397e34d704eeeb560eca1d Though since we harden PostgreSQL builds too, it is not an immediate issue. (In reply to Pavel Raiskup from comment #7) > Ok, thus 'perl -MExtUtils::Embed -e ccopts' should play some role here too. > I'll try to look at possible upstream patch. I completely forgot about this, so let's concentrate on upstream patch in 1462394. |