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 - postgresql-9.4.4-2.fc23 FTBFS: configure: error: libperl library is required for Perl
Summary: postgresql-9.4.4-2.fc23 FTBFS: configure: error: libperl library is required ...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL: http://koji.fedoraproject.org/koji/ta...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-14 08:38 UTC by Petr Pisar
Modified: 2017-06-22 11:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-15 16:35:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 947022 0 unspecified CLOSED postgresql package should be built with PIE flags 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1462394 0 unspecified CLOSED [upstream] postgresql --with-perl fails to build on rawhide due new perl 2021-02-22 00:41:40 UTC

Internal Links: 947022 1462394

Description Petr Pisar 2015-07-14 08:38:32 UTC
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

Difference between working and failing build root is:

        openssl-devel 	1:1.0.2c-3.fc23 	> 	1:1.0.2d-1.fc23
	m4 	1.4.17-6.fc23 	> 	1.4.17-8.fc23
	systemtap-sdt-devel 	2.9-0.20150707git... 	> 	2.9-0.20150713git...
	perl-ExtUtils-Embed 	1.32-346.fc23 	> 	1.32-347.fc23
	perl-devel 	4:5.22.0-346.fc23 	> 	4:5.22.0-347.fc23
	libseccomp 	2.2.1-1.fc23 	> 	2.2.3-0.fc23
	xz-libs 	5.2.1-2.fc23 	> 	5.2.1-3.fc23
	openssl-libs 	1:1.0.2c-3.fc23 	> 	1:1.0.2d-1.fc23
	xz-devel 	5.2.1-2.fc23 	> 	5.2.1-3.fc23
	perl 	4:5.22.0-346.fc23 	> 	4:5.22.0-347.fc23
	python3-pyparsing 		> 	2.0.3-2.fc23
	libidn 	1.30-4.fc23 	> 	1.31-1.fc23
	perl-libs 	4:5.22.0-346.fc23 	> 	4:5.22.0-347.fc23
	perl-Unicode-Normalize 		> 	1.19-1.fc23
	perl-Math-BigInt 		> 	1.9997-347.fc23
	perl-macros 	4:5.22.0-346.fc23 	> 	4:5.22.0-347.fc23
	perl-Term-Cap 		> 	1.16-1.fc23
	kernel-headers 	4.2.0-0.rc1.git1.1.... 	> 	4.2.0-0.rc1.git3.1....
	basesystem 	10.0-11.fc23 	> 	11-1.fc23
	perl-MIME-Base64 		> 	3.15-348.fc23
	perl-Pod-Escapes 	1:1.07-346.fc23 	> 	1:1.07-348.fc23
	gzip 	1.6-8.fc23 	> 	1.6-9.fc23
	python3-six 	1.9.0-2.fc23 	> 	1.9.0-3.fc23
	redhat-rpm-config 	33-2.fc23 	> 	34-1.fc23
	gdb 	7.9.50.20150531-5.fc23 	> 	7.9.90.20150709-6.fc23
	xz 	5.2.1-2.fc23 	> 	5.2.1-3.fc23
	gnutls 	3.4.2-3.fc23 	> 	3.4.3-1.fc23
	pyparsing 	2.0.3-2.fc23 	< 	
	dwz 	0.11-6.fc23 	> 	0.12-1.fc23

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.

I think relevant postgresql's bug report is bug #947022.

Comment 1 Pavel Raiskup 2015-07-14 11:17:43 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

Comment 2 Petr Pisar 2015-07-14 12:10:27 UTC
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.

Comment 3 Jan Kurik 2015-07-15 13:17:23 UTC
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

Comment 4 Pavel Raiskup 2015-07-16 11:37:15 UTC
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

Comment 5 Petr Pisar 2015-07-16 11:41:19 UTC
ldopts() are only linker flags. You are missing the compiler flags which will provide -fPIC.

Comment 6 Petr Pisar 2015-07-16 11:46:18 UTC
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".

Comment 7 Pavel Raiskup 2015-07-16 12:07:07 UTC
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).

Comment 8 Petr Pisar 2015-07-16 12:34:00 UTC
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.

Comment 9 Petr Pisar 2015-07-16 15:22:19 UTC
For you information, I disabled hardening in perl-5.22.0-349.

Comment 10 Pavel Raiskup 2015-10-15 16:35:53 UTC
Fedora 24+ has hardened PostgreSQL:
http://pkgs.fedoraproject.org/cgit/postgresql.git/commit/?id=72ca6afc2a7d65

Comment 11 Pavel Raiskup 2017-06-22 11:08:01 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.