Обсуждение: configure fails for perl check on CentOS8
Hello, While I'm moving to CentOS8 environment, I got stuck at
./configure with the following error.
configure: error: libperl library is requred for Perl
It complains that it needs -fPIC.
Configure uses only $Config{ccflags}, but it seems that
$Config{cccdlflags} is also required. The attached patch make
./configure success. (configure itself is excluded in the patch.)
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/config/perl.m4 b/config/perl.m4
index 059e31c476..8563ac7869 100644
--- a/config/perl.m4
+++ b/config/perl.m4
@@ -69,10 +69,10 @@ AC_DEFUN([PGAC_CHECK_PERL_CONFIGS],
AC_DEFUN([PGAC_CHECK_PERL_EMBED_CCFLAGS],
[AC_REQUIRE([PGAC_PATH_PERL])
AC_MSG_CHECKING([for CFLAGS recommended by Perl])
-perl_ccflags=`$PERL -MConfig -e ['print $Config{ccflags}']`
+perl_ccflags=`$PERL -MConfig -e ['print "$Config{ccflags} $Config{cccdlflags}"']`
AC_MSG_RESULT([$perl_ccflags])
AC_MSG_CHECKING([for CFLAGS to compile embedded Perl])
-perl_embed_ccflags=`$PERL -MConfig -e ['foreach $f (split(" ",$Config{ccflags})) {print $f, " " if ($f =~ /^-D[^_]/ ||
$f=~ /^-D_USE_32BIT_TIME_T/)}']`
+perl_embed_ccflags=`$PERL -MConfig -e ['foreach $f (split(" ",$Config{ccflags})) {print $f, " " if ($f =~ /^-D[^_]/ ||
$f=~ /^-D_USE_32BIT_TIME_T/)} print "$Config{cccdlflags} "']`
AC_SUBST(perl_embed_ccflags)dnl
AC_MSG_RESULT([$perl_embed_ccflags])
])# PGAC_CHECK_PERL_EMBED_CCFLAGS
diff --git a/configure.in b/configure.in
index 0d16c1a971..47770f54f0 100644
--- a/configure.in
+++ b/configure.in
@@ -2223,7 +2223,7 @@ fi
# check for <perl.h>
if test "$with_perl" = yes; then
ac_save_CPPFLAGS=$CPPFLAGS
- CPPFLAGS="$CPPFLAGS $perl_includespec"
+ CPPFLAGS="$CPPFLAGS $perl_includespec $perl_embed_ccflags"
AC_CHECK_HEADER(perl.h, [], [AC_MSG_ERROR([header file <perl.h> is required for Perl])],
[#include <EXTERN.h>])
# While we're at it, check that we can link to libperl.
On 10/10/19 1:46 AM, Kyotaro Horiguchi wrote:
> Hello, While I'm moving to CentOS8 environment, I got stuck at
> ./configure with the following error.
>
> configure: error: libperl library is requred for Perl
>
> It complains that it needs -fPIC.
>
> Configure uses only $Config{ccflags}, but it seems that
> $Config{cccdlflags} is also required. The attached patch make
> ./configure success. (configure itself is excluded in the patch.)
>
./configure --with-perl
is working for me on Centos8 (double checked after a `dnf update`)
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 10/10/19 1:46 AM, Kyotaro Horiguchi wrote:
>> Hello, While I'm moving to CentOS8 environment, I got stuck at
>> ./configure with the following error.
>> configure: error: libperl library is requred for Perl
>> It complains that it needs -fPIC.
>> Configure uses only $Config{ccflags}, but it seems that
>> $Config{cccdlflags} is also required. The attached patch make
>> ./configure success. (configure itself is excluded in the patch.)
> ./configure --with-perl
> is working for me on Centos8 (double checked after a `dnf update`)
Yeah, I'm quite suspicious of this too. Although we don't seem to have
any buildfarm members covering exactly RHEL8/CentOS8, we have enough
coverage of different Fedora releases to make it hard to believe that
we missed any changes in Red Hat's packaging of Perl.
Is this error perhaps occurring with a non-vendor Perl installation?
What's the exact error message? config.log might contain some useful
clues, too.
regards, tom lane
Hi. Sorry for the delay.
At Thu, 10 Oct 2019 11:51:21 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 10/10/19 1:46 AM, Kyotaro Horiguchi wrote:
> >> Hello, While I'm moving to CentOS8 environment, I got stuck at
> >> ./configure with the following error.
> >> configure: error: libperl library is requred for Perl
> >> It complains that it needs -fPIC.
> >> Configure uses only $Config{ccflags}, but it seems that
> >> $Config{cccdlflags} is also required. The attached patch make
> >> ./configure success. (configure itself is excluded in the patch.)
>
> > ./configure --with-perl
> > is working for me on Centos8 (double checked after a `dnf update`)
>
> Yeah, I'm quite suspicious of this too. Although we don't seem to have
> any buildfarm members covering exactly RHEL8/CentOS8, we have enough
> coverage of different Fedora releases to make it hard to believe that
> we missed any changes in Red Hat's packaging of Perl.
>
> Is this error perhaps occurring with a non-vendor Perl installation?
> What's the exact error message? config.log might contain some useful
> clues, too.
The perl package is official one. I found the cause, that's my
mistake.
The problematic command line boils down to:
$ ./configure --with-perl CFLAGS=-O0
It is bash-aliased and survived without being found for a long time on
my Cent7 environment, but CentOS8 doesn't allow that.
By the way, is there any official way to specify options like -O0
while configure time?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Tue, Oct 15, 2019 at 6:45 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > > > Is this error perhaps occurring with a non-vendor Perl installation? > > What's the exact error message? config.log might contain some useful > > clues, too. > > The perl package is official one. I found the cause, that's my > mistake. > > The problematic command line boils down to: > > $ ./configure --with-perl CFLAGS=-O0 > > It is bash-aliased and survived without being found for a long time on > my Cent7 environment, but CentOS8 doesn't allow that. > > By the way, is there any official way to specify options like -O0 > while configure time? > CFLAGS=-O0 configure --with-perl ... cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On Tue, Oct 15, 2019 at 6:45 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
>> The problematic command line boils down to:
>> $ ./configure --with-perl CFLAGS=-O0
>> It is bash-aliased and survived without being found for a long time on
>> my Cent7 environment, but CentOS8 doesn't allow that.
I don't quite understand why that wouldn't work.
>> By the way, is there any official way to specify options like -O0
>> while configure time?
> CFLAGS=-O0 configure --with-perl ...
The way Horiguchi-san did it has been supported by autoconf for
a good long time now, so I don't think command line syntax is
the issue. Could that CFLAGS setting be interfering with some
feature test in our configure script?
regards, tom lane
On Wed, Oct 16, 2019 at 8:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > > On Tue, Oct 15, 2019 at 6:45 AM Kyotaro Horiguchi > > <horikyota.ntt@gmail.com> wrote: > >> The problematic command line boils down to: > >> $ ./configure --with-perl CFLAGS=-O0 > >> It is bash-aliased and survived without being found for a long time on > >> my Cent7 environment, but CentOS8 doesn't allow that. > > I don't quite understand why that wouldn't work. > > >> By the way, is there any official way to specify options like -O0 > >> while configure time? > > > CFLAGS=-O0 configure --with-perl ... > > The way Horiguchi-san did it has been supported by autoconf for > a good long time now, so I don't think command line syntax is > the issue. Ah. > Could that CFLAGS setting be interfering with some > feature test in our configure script? > > It looks like you need CFLAGS='-O0 -fPIC' on CentOS 8 when building with perl. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello. # I'm almost comming back.. At Wed, 16 Oct 2019 10:41:19 -0400, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote in > On Wed, Oct 16, 2019 at 8:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> $ ./configure --with-perl CFLAGS=-O0 > > >> It is bash-aliased and survived without being found for a long time on > > >> my Cent7 environment, but CentOS8 doesn't allow that. > > > > I don't quite understand why that wouldn't work. I'm confused with make CFLAGS=.. > It looks like you need CFLAGS='-O0 -fPIC' on CentOS 8 when building with perl. Yes, that is what my first mail said. I dug into it further. The immediately problematic command generated by autoconf is: gcc -o /tmp/conftest -Wall -Wmissing-prototypes -Wpointer-arith \ -Wdeclaration-after-statement -Werror=vla -Wendif-labels \ -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing \ -fwrapv -fexcess-precision=standard -Wno-format-truncation \ -Wno-stringop-truncation \ -O0 \ -D_GNU_SOURCE -I/usr/lib64/perl5/CORE \ /tmp/conftest.c \ -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -fstack-protector-strong -L/usr/local/lib -L/usr/lib64/perl5/CORE \ -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil -lc /usr/bin/ld: /tmp/ccGxodNv.o: relocation R_X86_64_32 against symbol `PL_memory_wrap' can not be used when making a PIE object;recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status Very interestingly I don't get the error when the "-O0" is "-O2". It is because gcc eliminates the PL_memory_wrap maybe by inlining. The *final* problematic command boils down to: gcc -o /tmp/conftest /tmp/conftest_O0.o \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lperl That is, the problem doesn't happen without "-specs=/usr/lib/rpm/redhat/redhat-hardened-ld". I found the following bug report but it hasn't ever been fixed since 2016 on Fedora 24. I'm not sure about the newer versions. https://bugzilla.redhat.com/show_bug.cgi?id=1343892 -- Kyotaro Horiguchi NTT Open Source Software Center
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> The immediately problematic command generated by autoconf is:
> ...
> /usr/bin/ld: /tmp/ccGxodNv.o: relocation R_X86_64_32 against symbol `PL_memory_wrap' can not be used when making a
PIEobject; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> Very interestingly I don't get the error when the "-O0" is "-O2". It
> is because gcc eliminates the PL_memory_wrap maybe by inlining.
Yeah, probably so. But I don't like the idea of fixing a problem
triggered by user-supplied CFLAGS by injecting more cflags from
elsewhere. That seems likely to be counterproductive, or at
least it risks overriding what the user wanted.
Can we fix this by using something other than perl_alloc() as
the tested-for function? That is surely a pretty arbitrary
choice. Are there any standard Perl entry points that are just
plain functions with no weird macro expansions?
regards, tom lane
On 10/18/19 9:50 AM, Tom Lane wrote: > Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes: >> The immediately problematic command generated by autoconf is: >> ... >> /usr/bin/ld: /tmp/ccGxodNv.o: relocation R_X86_64_32 against symbol `PL_memory_wrap' can not be used when making a PIEobject; recompile with -fPIC >> /usr/bin/ld: final link failed: Nonrepresentable section on output >> collect2: error: ld returned 1 exit status >> Very interestingly I don't get the error when the "-O0" is "-O2". It >> is because gcc eliminates the PL_memory_wrap maybe by inlining. > Yeah, probably so. But I don't like the idea of fixing a problem > triggered by user-supplied CFLAGS by injecting more cflags from > elsewhere. That seems likely to be counterproductive, or at > least it risks overriding what the user wanted. > > Can we fix this by using something other than perl_alloc() as > the tested-for function? That is surely a pretty arbitrary > choice. Are there any standard Perl entry points that are just > plain functions with no weird macro expansions? > I had a look in perl's proto.h but didn't see any obvious candidate. I tried a couple of others (e.g. Perl_get_context) and got the same result reported above. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 10/18/19 9:50 AM, Tom Lane wrote:
>> Can we fix this by using something other than perl_alloc() as
>> the tested-for function? That is surely a pretty arbitrary
>> choice. Are there any standard Perl entry points that are just
>> plain functions with no weird macro expansions?
> I had a look in perl's proto.h but didn't see any obvious candidate. I
> tried a couple of others (e.g. Perl_get_context) and got the same result
> reported above.
I poked into this on a Fedora 30 installation and determined that the
stray reference is coming from this bit in Perl's inline.h:
/* saves machine code for a common noreturn idiom typically used in Newx*() */
GCC_DIAG_IGNORE_DECL(-Wunused-function);
static void
S_croak_memory_wrap(void)
{
Perl_croak_nocontext("%s",PL_memory_wrap);
}
GCC_DIAG_RESTORE_DECL;
Apparently, gcc is smart enough to optimize this away as unused ...
at any optimization level higher than -O0. I confirmed that it works
at -O0 too, if you change this function declaration to "static inline"
--- but evidently, not doing so was intentional, so we won't get much
cooperation if we propose changing it (back?) to a plain static inline.
So the failure occurs just from reading this header, independently of
which particular Perl function we try to call; I'd supposed that there
was some connection between perl_alloc and PL_memory_wrap, but there
isn't.
I still don't much like the originally proposed patch. IMO it makes too
many assumptions about what is in Perl's ccflags, and perhaps more to the
point, it is testing libperl's linkability using switches we will not use
when we actually build plperl. So I think there's a pretty high risk of
breaking other cases if we fix it that way.
The right way to fix it, likely, is to add CFLAGS_SL while performing this
particular autoconf test, as that would replicate the switches used for
plperl (and it turns out that adding -fPIC does solve this problem).
But the configure script doesn't currently know about CFLAGS_SL, so we'd
have to do some refactoring to approach it that way. Moving that logic
from the platform-specific Makefiles into configure doesn't seem
unreasonable, but it would make the patch bigger.
A less invasive idea is to forcibly add -O1 to CFLAGS for this autoconf
test. We'd have to be careful about doing so for non-gcc compilers, as
they might not understand that switch syntax ... but probably we could
get away with changing CFLAGS only when using a gcc-alike. Still, that's
a hack, and it doesn't have much to recommend it other than being more
localized.
regards, tom lane
On 10/20/19 1:23 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 10/18/19 9:50 AM, Tom Lane wrote:
>>> Can we fix this by using something other than perl_alloc() as
>>> the tested-for function? That is surely a pretty arbitrary
>>> choice. Are there any standard Perl entry points that are just
>>> plain functions with no weird macro expansions?
>> I had a look in perl's proto.h but didn't see any obvious candidate. I
>> tried a couple of others (e.g. Perl_get_context) and got the same result
>> reported above.
> I poked into this on a Fedora 30 installation and determined that the
> stray reference is coming from this bit in Perl's inline.h:
>
> /* saves machine code for a common noreturn idiom typically used in Newx*() */
> GCC_DIAG_IGNORE_DECL(-Wunused-function);
> static void
> S_croak_memory_wrap(void)
> {
> Perl_croak_nocontext("%s",PL_memory_wrap);
> }
> GCC_DIAG_RESTORE_DECL;
>
> Apparently, gcc is smart enough to optimize this away as unused ...
> at any optimization level higher than -O0. I confirmed that it works
> at -O0 too, if you change this function declaration to "static inline"
> --- but evidently, not doing so was intentional, so we won't get much
> cooperation if we propose changing it (back?) to a plain static inline.
>
> So the failure occurs just from reading this header, independently of
> which particular Perl function we try to call; I'd supposed that there
> was some connection between perl_alloc and PL_memory_wrap, but there
> isn't.
Yeah, I came to the same conclusion.
>
> I still don't much like the originally proposed patch. IMO it makes too
> many assumptions about what is in Perl's ccflags, and perhaps more to the
> point, it is testing libperl's linkability using switches we will not use
> when we actually build plperl. So I think there's a pretty high risk of
> breaking other cases if we fix it that way.
Agreed.
>
> The right way to fix it, likely, is to add CFLAGS_SL while performing this
> particular autoconf test, as that would replicate the switches used for
> plperl (and it turns out that adding -fPIC does solve this problem).
> But the configure script doesn't currently know about CFLAGS_SL, so we'd
> have to do some refactoring to approach it that way. Moving that logic
> from the platform-specific Makefiles into configure doesn't seem
> unreasonable, but it would make the patch bigger.
Sounds like a plan. I agree it's annoying to have to do something large
for something so trivial.
>
> A less invasive idea is to forcibly add -O1 to CFLAGS for this autoconf
> test. We'd have to be careful about doing so for non-gcc compilers, as
> they might not understand that switch syntax ... but probably we could
> get away with changing CFLAGS only when using a gcc-alike. Still, that's
> a hack, and it doesn't have much to recommend it other than being more
> localized.
>
>
right. I think your other plan is better.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 10/20/19 1:23 PM, Tom Lane wrote:
>> The right way to fix it, likely, is to add CFLAGS_SL while performing this
>> particular autoconf test, as that would replicate the switches used for
>> plperl (and it turns out that adding -fPIC does solve this problem).
>> But the configure script doesn't currently know about CFLAGS_SL, so we'd
>> have to do some refactoring to approach it that way. Moving that logic
>> from the platform-specific Makefiles into configure doesn't seem
>> unreasonable, but it would make the patch bigger.
> Sounds like a plan. I agree it's annoying to have to do something large
> for something so trivial.
Turns out it's not really that bad. We just have to transfer the
responsibility for setting CFLAGS_SL from the platform Makefiles
to the platform template files. (As a bonus, it'd be possible to
allow users to override CFLAGS_SL during configure, as they can
do for CFLAGS. But I didn't mess with that here.)
I checked that this fixes the Fedora build problem, but I've not
really tested it on any other platform. Still, there's not that
much to go wrong, one would think.
regards, tom lane
diff --git a/configure b/configure
index 02a905b..1d664a4 100755
--- a/configure
+++ b/configure
@@ -728,6 +728,7 @@ autodepend
TAS
GCC
CPP
+CFLAGS_SL
BITCODE_CXXFLAGS
BITCODE_CFLAGS
CFLAGS_VECTOR
@@ -6579,7 +6580,6 @@ fi
fi
-CFLAGS_VECTOR=$CFLAGS_VECTOR
# Determine flags used to emit bitcode for JIT inlining. Need to test
@@ -6899,9 +6899,10 @@ CXXFLAGS="$CXXFLAGS $user_CXXFLAGS"
BITCODE_CFLAGS="$BITCODE_CFLAGS $user_BITCODE_CFLAGS"
BITCODE_CXXFLAGS="$BITCODE_CXXFLAGS $user_BITCODE_CXXFLAGS"
-BITCODE_CFLAGS=$BITCODE_CFLAGS
-BITCODE_CXXFLAGS=$BITCODE_CXXFLAGS
+
+
+# The template file must set up CFLAGS_SL; we don't support user override
# Check if the compiler still works with the final flag settings
diff --git a/configure.in b/configure.in
index 88d3a59..50f4b26 100644
--- a/configure.in
+++ b/configure.in
@@ -547,7 +547,7 @@ elif test "$PORTNAME" = "hpux"; then
PGAC_PROG_CXX_CFLAGS_OPT([+Olibmerrno])
fi
-AC_SUBST(CFLAGS_VECTOR, $CFLAGS_VECTOR)
+AC_SUBST(CFLAGS_VECTOR)
# Determine flags used to emit bitcode for JIT inlining. Need to test
# for behaviour changing compiler flags, to keep compatibility with
@@ -607,8 +607,11 @@ CXXFLAGS="$CXXFLAGS $user_CXXFLAGS"
BITCODE_CFLAGS="$BITCODE_CFLAGS $user_BITCODE_CFLAGS"
BITCODE_CXXFLAGS="$BITCODE_CXXFLAGS $user_BITCODE_CXXFLAGS"
-AC_SUBST(BITCODE_CFLAGS, $BITCODE_CFLAGS)
-AC_SUBST(BITCODE_CXXFLAGS, $BITCODE_CXXFLAGS)
+AC_SUBST(BITCODE_CFLAGS)
+AC_SUBST(BITCODE_CXXFLAGS)
+
+# The template file must set up CFLAGS_SL; we don't support user override
+AC_SUBST(CFLAGS_SL)
# Check if the compiler still works with the final flag settings
# (note, we're not checking that for CXX, which is optional)
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 2d21068..05b6638 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -258,6 +258,7 @@ GCC = @GCC@
SUN_STUDIO_CC = @SUN_STUDIO_CC@
CXX = @CXX@
CFLAGS = @CFLAGS@
+CFLAGS_SL = @CFLAGS_SL@
CFLAGS_VECTOR = @CFLAGS_VECTOR@
CFLAGS_SSE42 = @CFLAGS_SSE42@
CFLAGS_ARMV8_CRC32C = @CFLAGS_ARMV8_CRC32C@
diff --git a/src/makefiles/Makefile.cygwin b/src/makefiles/Makefile.cygwin
index f274d80..81089d6 100644
--- a/src/makefiles/Makefile.cygwin
+++ b/src/makefiles/Makefile.cygwin
@@ -12,7 +12,6 @@ LIBS:=$(filter-out -lm -lc, $(LIBS))
AROPT = crs
DLSUFFIX = .dll
-CFLAGS_SL =
override CPPFLAGS += -DWIN32_STACK_RLIMIT=$(WIN32_STACK_RLIMIT)
diff --git a/src/makefiles/Makefile.freebsd b/src/makefiles/Makefile.freebsd
index c462e2f..75db21b 100644
--- a/src/makefiles/Makefile.freebsd
+++ b/src/makefiles/Makefile.freebsd
@@ -5,8 +5,6 @@ rpath = -Wl,-R'$(rpathdir)'
DLSUFFIX = .so
-CFLAGS_SL = -fPIC -DPIC
-
# extra stuff for $(with_temp_install)
# we need this to get LD_LIBRARY_PATH searched ahead of the compiled-in
# rpath, if no DT_RUNPATH is present in the executable. The conditions
diff --git a/src/makefiles/Makefile.hpux b/src/makefiles/Makefile.hpux
index c871fb0..7e18770 100644
--- a/src/makefiles/Makefile.hpux
+++ b/src/makefiles/Makefile.hpux
@@ -30,11 +30,6 @@ ifeq ($(host_cpu), ia64)
else
DLSUFFIX = .sl
endif
-ifeq ($(GCC), yes)
- CFLAGS_SL = -fPIC
-else
- CFLAGS_SL = +Z
-endif
# env var name to use in place of LD_LIBRARY_PATH
ld_library_path_var = SHLIB_PATH
diff --git a/src/makefiles/Makefile.linux b/src/makefiles/Makefile.linux
index ac58fe4..645f73a 100644
--- a/src/makefiles/Makefile.linux
+++ b/src/makefiles/Makefile.linux
@@ -7,8 +7,6 @@ rpath = -Wl,-rpath,'$(rpathdir)',--enable-new-dtags
DLSUFFIX = .so
-CFLAGS_SL = -fPIC
-
# Rule for building a shared library from a single .o file
%.so: %.o
diff --git a/src/makefiles/Makefile.netbsd b/src/makefiles/Makefile.netbsd
index 15695fb..6f9cb1d 100644
--- a/src/makefiles/Makefile.netbsd
+++ b/src/makefiles/Makefile.netbsd
@@ -5,8 +5,6 @@ rpath = -Wl,-R'$(rpathdir)'
DLSUFFIX = .so
-CFLAGS_SL = -fPIC -DPIC
-
# Rule for building a shared library from a single .o file
%.so: %.o
diff --git a/src/makefiles/Makefile.openbsd b/src/makefiles/Makefile.openbsd
index 15695fb..6f9cb1d 100644
--- a/src/makefiles/Makefile.openbsd
+++ b/src/makefiles/Makefile.openbsd
@@ -5,8 +5,6 @@ rpath = -Wl,-R'$(rpathdir)'
DLSUFFIX = .so
-CFLAGS_SL = -fPIC -DPIC
-
# Rule for building a shared library from a single .o file
%.so: %.o
diff --git a/src/makefiles/Makefile.solaris b/src/makefiles/Makefile.solaris
index a7f5652..62a6c01 100644
--- a/src/makefiles/Makefile.solaris
+++ b/src/makefiles/Makefile.solaris
@@ -10,11 +10,7 @@ rpath = -Wl,-R'$(rpathdir)'
endif
DLSUFFIX = .so
-ifeq ($(GCC), yes)
-CFLAGS_SL = -fPIC
-else
-CFLAGS_SL = -KPIC
-endif
+
# Rule for building a shared library from a single .o file
%.so: %.o
diff --git a/src/makefiles/Makefile.win32 b/src/makefiles/Makefile.win32
index 3dea11e..8a7d6ff 100644
--- a/src/makefiles/Makefile.win32
+++ b/src/makefiles/Makefile.win32
@@ -12,7 +12,6 @@ override CPPFLAGS += -DWIN32_STACK_RLIMIT=$(WIN32_STACK_RLIMIT)
AROPT = crs
DLSUFFIX = .dll
-CFLAGS_SL =
ifneq (,$(findstring backend,$(subdir)))
ifeq (,$(findstring conversion_procs,$(subdir)))
diff --git a/src/template/aix b/src/template/aix
index 999cd35..cec240d 100644
--- a/src/template/aix
+++ b/src/template/aix
@@ -1,3 +1,5 @@
+# src/template/aix
+
# Set default options if using xlc. This formerly included -qsrcmsg, but that
# option elicits internal compiler errors from xlc v16.1.0. Note: configure
# will add -qnoansialias if the compiler accepts it, even if user specifies a
@@ -17,6 +19,9 @@ if test "$GCC" != yes ; then
FORCE_DISABLE_RESTRICT=yes
fi
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL=""
+
# Native memset() is faster, tested on:
# AIX 5.1 and 5.2, XLC 6.0 (IBM's cc)
# AIX 5.3 ML3, gcc 4.0.1
diff --git a/src/template/cygwin b/src/template/cygwin
index b6ea0de..79a1081 100644
--- a/src/template/cygwin
+++ b/src/template/cygwin
@@ -2,6 +2,9 @@
SRCH_LIB="/usr/local/lib"
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL=""
+
# --allow-multiple-definition is required to link pg_dump because it finds
# pg_toupper() etc. in both libpq and pgport
# we'd prefer to use --disable-auto-import to match MSVC linking behavior,
diff --git a/src/template/darwin b/src/template/darwin
index c05adca..f4d4e9d 100644
--- a/src/template/darwin
+++ b/src/template/darwin
@@ -16,6 +16,9 @@ if test x"$PG_SYSROOT" != x"" ; then
fi
fi
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL=""
+
# Select appropriate semaphore support. Darwin 6.0 (macOS 10.2) and up
# support System V semaphores; before that we have to use named POSIX
# semaphores, which are less good for our purposes because they eat a
diff --git a/src/template/freebsd b/src/template/freebsd
index a82d5a4..41fa4a1 100644
--- a/src/template/freebsd
+++ b/src/template/freebsd
@@ -4,3 +4,6 @@
if test x"$PREFERRED_SEMAPHORES" = x"" ; then
PREFERRED_SEMAPHORES=UNNAMED_POSIX
fi
+
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL="-fPIC -DPIC"
diff --git a/src/template/hpux b/src/template/hpux
index 79d3475..50fff80 100644
--- a/src/template/hpux
+++ b/src/template/hpux
@@ -8,6 +8,13 @@ if test "$GCC" != yes ; then
CFLAGS="+O2"
fi
+# Extra CFLAGS for code that will go into a shared library
+if test "$GCC" = yes ; then
+ CFLAGS_SL="-fPIC"
+else
+ CFLAGS_SL="+Z"
+fi
+
# Pick right test-and-set (TAS) code. We need out-of-line assembler
# when not using gcc.
case $host in
diff --git a/src/template/linux b/src/template/linux
index e392908..ec3302c 100644
--- a/src/template/linux
+++ b/src/template/linux
@@ -9,6 +9,9 @@ fi
# This is also required for ppoll(2), and perhaps other things
CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL="-fPIC"
+
# If --enable-profiling is specified, we need -DLINUX_PROFILE
PLATFORM_PROFILE_FLAGS="-DLINUX_PROFILE"
diff --git a/src/template/netbsd b/src/template/netbsd
index 1986977..d97f995 100644
--- a/src/template/netbsd
+++ b/src/template/netbsd
@@ -1,2 +1,5 @@
# src/template/netbsd
# tools/thread/thread_test must be run
+
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL="-fPIC -DPIC"
diff --git a/src/template/openbsd b/src/template/openbsd
index e69de29..365268c 100644
--- a/src/template/openbsd
+++ b/src/template/openbsd
@@ -0,0 +1,4 @@
+# src/template/openbsd
+
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL="-fPIC -DPIC"
diff --git a/src/template/solaris b/src/template/solaris
index e07b9a0..f88b1cd 100644
--- a/src/template/solaris
+++ b/src/template/solaris
@@ -1,3 +1,12 @@
+# src/template/solaris
+
+# Extra CFLAGS for code that will go into a shared library
+if test "$GCC" = yes ; then
+ CFLAGS_SL="-fPIC"
+else
+ CFLAGS_SL="-KPIC"
+fi
+
if test "$SUN_STUDIO_CC" = yes ; then
CC="$CC -Xa" # relaxed ISO C mode
CFLAGS="-v" # -v is like gcc -Wall
diff --git a/src/template/win32 b/src/template/win32
index 7da9719..1380d16 100644
--- a/src/template/win32
+++ b/src/template/win32
@@ -1,5 +1,8 @@
# src/template/win32
+# Extra CFLAGS for code that will go into a shared library
+CFLAGS_SL=""
+
# --allow-multiple-definition is required to link pg_dump because it finds
# pg_toupper() etc. in both libpq and pgport
# --disable-auto-import is to ensure we get MSVC-like linking behavior
diff --git a/configure b/configure
index 1d664a4..6b1c779 100755
--- a/configure
+++ b/configure
@@ -18490,6 +18490,10 @@ fi
# On most platforms, if perl.h is there then libperl.so will be too, but at
# this writing Debian packages them separately. There is no known reason to
# waste cycles on separate probes for the Tcl or Python libraries, though.
+ # On some Red Hat platforms, the link attempt can fail if we don't use
+ # CFLAGS_SL while building the test program.
+ ac_save_CFLAGS=$CFLAGS
+ CFLAGS="$CFLAGS $CFLAGS_SL"
pgac_save_LIBS=$LIBS
LIBS="$perl_embed_ldflags"
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for libperl" >&5
@@ -18519,6 +18523,7 @@ fi
rm -f core conftest.err conftest.$ac_objext \
conftest$ac_exeext conftest.$ac_ext
LIBS=$pgac_save_LIBS
+ CFLAGS=$ac_save_CFLAGS
CPPFLAGS=$ac_save_CPPFLAGS
fi
diff --git a/configure.in b/configure.in
index 50f4b26..2b9025c 100644
--- a/configure.in
+++ b/configure.in
@@ -2253,6 +2253,10 @@ if test "$with_perl" = yes; then
# On most platforms, if perl.h is there then libperl.so will be too, but at
# this writing Debian packages them separately. There is no known reason to
# waste cycles on separate probes for the Tcl or Python libraries, though.
+ # On some Red Hat platforms, the link attempt can fail if we don't use
+ # CFLAGS_SL while building the test program.
+ ac_save_CFLAGS=$CFLAGS
+ CFLAGS="$CFLAGS $CFLAGS_SL"
pgac_save_LIBS=$LIBS
LIBS="$perl_embed_ldflags"
AC_MSG_CHECKING([for libperl])
@@ -2264,6 +2268,7 @@ if test "$with_perl" = yes; then
[AC_MSG_RESULT(no)
AC_MSG_ERROR([libperl library is required for Perl])])
LIBS=$pgac_save_LIBS
+ CFLAGS=$ac_save_CFLAGS
CPPFLAGS=$ac_save_CPPFLAGS
fi
On 10/20/19 7:36 PM, Tom Lane wrote: > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: >> On 10/20/19 1:23 PM, Tom Lane wrote: >>> The right way to fix it, likely, is to add CFLAGS_SL while performing this >>> particular autoconf test, as that would replicate the switches used for >>> plperl (and it turns out that adding -fPIC does solve this problem). >>> But the configure script doesn't currently know about CFLAGS_SL, so we'd >>> have to do some refactoring to approach it that way. Moving that logic >>> from the platform-specific Makefiles into configure doesn't seem >>> unreasonable, but it would make the patch bigger. >> Sounds like a plan. I agree it's annoying to have to do something large >> for something so trivial. > Turns out it's not really that bad. We just have to transfer the > responsibility for setting CFLAGS_SL from the platform Makefiles > to the platform template files. (As a bonus, it'd be possible to > allow users to override CFLAGS_SL during configure, as they can > do for CFLAGS. But I didn't mess with that here.) > > I checked that this fixes the Fedora build problem, but I've not > really tested it on any other platform. Still, there's not that > much to go wrong, one would think. > > LGTM cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello. At Mon, 21 Oct 2019 08:29:39 -0400, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote in > > On 10/20/19 7:36 PM, Tom Lane wrote: > > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > >> On 10/20/19 1:23 PM, Tom Lane wrote: > >>> The right way to fix it, likely, is to add CFLAGS_SL while performing this > >>> particular autoconf test, as that would replicate the switches used for > >>> plperl (and it turns out that adding -fPIC does solve this problem). > >>> But the configure script doesn't currently know about CFLAGS_SL, so we'd > >>> have to do some refactoring to approach it that way. Moving that logic > >>> from the platform-specific Makefiles into configure doesn't seem > >>> unreasonable, but it would make the patch bigger. > >> Sounds like a plan. I agree it's annoying to have to do something large > >> for something so trivial. > > Turns out it's not really that bad. We just have to transfer the > > responsibility for setting CFLAGS_SL from the platform Makefiles > > to the platform template files. (As a bonus, it'd be possible to > > allow users to override CFLAGS_SL during configure, as they can > > do for CFLAGS. But I didn't mess with that here.) > > > > I checked that this fixes the Fedora build problem, but I've not > > really tested it on any other platform. Still, there's not that > > much to go wrong, one would think. > > > > LGTM However it's done, but it looks good to me and actually the problem is gone. Thaks! regards. -- Kyotaro Horiguchi NTT Open Source Software Center