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.