2010-09-21 04:08:53 +08:00
|
|
|
# config/perl.m4
|
2001-08-27 06:28:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
# PGAC_PATH_PERL
|
|
|
|
|
# --------------
|
|
|
|
|
AC_DEFUN([PGAC_PATH_PERL],
|
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
|
|
|
[PGAC_PATH_PROGS(PERL, perl)
|
2019-01-18 15:29:42 +08:00
|
|
|
AC_ARG_VAR(PERL, [Perl program])dnl
|
2010-01-07 09:41:11 +08:00
|
|
|
|
|
|
|
|
if test "$PERL"; then
|
2010-02-24 02:35:07 +08:00
|
|
|
pgac_perl_version=`$PERL -v 2>/dev/null | sed -n ['s/This is perl.*v[a-z ]*\([0-9]\.[0-9][0-9.]*\).*$/\1/p']`
|
2010-01-07 09:41:11 +08:00
|
|
|
AC_MSG_NOTICE([using perl $pgac_perl_version])
|
|
|
|
|
if echo "$pgac_perl_version" | sed ['s/[.a-z_]/ /g'] | \
|
2022-09-14 10:58:13 +08:00
|
|
|
$AWK '{ if ([$]1 == 5 && ([$]2 >= 14)) exit 1; else exit 0;}'
|
2010-01-07 09:41:11 +08:00
|
|
|
then
|
Remove distprep
A PostgreSQL release tarball contains a number of prebuilt files, in
particular files produced by bison, flex, perl, and well as html and
man documentation. We have done this consistent with established
practice at the time to not require these tools for building from a
tarball. Some of these tools were hard to get, or get the right
version of, from time to time, and shipping the prebuilt output was a
convenience to users.
Now this has at least two problems:
One, we have to make the build system(s) work in two modes: Building
from a git checkout and building from a tarball. This is pretty
complicated, but it works so far for autoconf/make. It does not
currently work for meson; you can currently only build with meson from
a git checkout. Making meson builds work from a tarball seems very
difficult or impossible. One particular problem is that since meson
requires a separate build directory, we cannot make the build update
files like gram.h in the source tree. So if you were to build from a
tarball and update gram.y, you will have a gram.h in the source tree
and one in the build tree, but the way things work is that the
compiler will always use the one in the source tree. So you cannot,
for example, make any gram.y changes when building from a tarball.
This seems impossible to fix in a non-horrible way.
Second, there is increased interest nowadays in precisely tracking the
origin of software. We can reasonably track contributions into the
git tree, and users can reasonably track the path from a tarball to
packages and downloads and installs. But what happens between the git
tree and the tarball is obscure and in some cases non-reproducible.
The solution for both of these issues is to get rid of the step that
adds prebuilt files to the tarball. The tarball now only contains
what is in the git tree (*). Getting the additional build
dependencies is no longer a problem nowadays, and the complications to
keep these dual build modes working are significant. And of course we
want to get the meson build system working universally.
This commit removes the make distprep target altogether. The make
dist target continues to do its job, it just doesn't call distprep
anymore.
(*) - The tarball also contains the INSTALL file that is built at make
dist time, but not by distprep. This is unchanged for now.
The make maintainer-clean target, whose job it is to remove the
prebuilt files in addition to what make distclean does, is now just an
alias to make distprep. (In practice, it is probably obsolete given
that git clean is available.)
The following programs are now hard build requirements in configure
(they were already required by meson.build):
- bison
- flex
- perl
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
2023-11-06 21:51:52 +08:00
|
|
|
AC_MSG_ERROR([
|
2010-01-07 09:41:11 +08:00
|
|
|
*** The installed version of Perl, $PERL, is too old to use with PostgreSQL.
|
2022-09-14 10:58:13 +08:00
|
|
|
*** Perl version 5.14 or later is required, but this is $pgac_perl_version.])
|
2010-01-07 09:41:11 +08:00
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
if test -z "$PERL"; then
|
Remove distprep
A PostgreSQL release tarball contains a number of prebuilt files, in
particular files produced by bison, flex, perl, and well as html and
man documentation. We have done this consistent with established
practice at the time to not require these tools for building from a
tarball. Some of these tools were hard to get, or get the right
version of, from time to time, and shipping the prebuilt output was a
convenience to users.
Now this has at least two problems:
One, we have to make the build system(s) work in two modes: Building
from a git checkout and building from a tarball. This is pretty
complicated, but it works so far for autoconf/make. It does not
currently work for meson; you can currently only build with meson from
a git checkout. Making meson builds work from a tarball seems very
difficult or impossible. One particular problem is that since meson
requires a separate build directory, we cannot make the build update
files like gram.h in the source tree. So if you were to build from a
tarball and update gram.y, you will have a gram.h in the source tree
and one in the build tree, but the way things work is that the
compiler will always use the one in the source tree. So you cannot,
for example, make any gram.y changes when building from a tarball.
This seems impossible to fix in a non-horrible way.
Second, there is increased interest nowadays in precisely tracking the
origin of software. We can reasonably track contributions into the
git tree, and users can reasonably track the path from a tarball to
packages and downloads and installs. But what happens between the git
tree and the tarball is obscure and in some cases non-reproducible.
The solution for both of these issues is to get rid of the step that
adds prebuilt files to the tarball. The tarball now only contains
what is in the git tree (*). Getting the additional build
dependencies is no longer a problem nowadays, and the complications to
keep these dual build modes working are significant. And of course we
want to get the meson build system working universally.
This commit removes the make distprep target altogether. The make
dist target continues to do its job, it just doesn't call distprep
anymore.
(*) - The tarball also contains the INSTALL file that is built at make
dist time, but not by distprep. This is unchanged for now.
The make maintainer-clean target, whose job it is to remove the
prebuilt files in addition to what make distclean does, is now just an
alias to make distprep. (In practice, it is probably obsolete given
that git clean is available.)
The following programs are now hard build requirements in configure
(they were already required by meson.build):
- bison
- flex
- perl
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
2023-11-06 21:51:52 +08:00
|
|
|
AC_MSG_ERROR([Perl not found])
|
2010-01-07 09:41:11 +08:00
|
|
|
fi
|
|
|
|
|
])# PGAC_PATH_PERL
|
2001-08-27 06:28:04 +08:00
|
|
|
|
|
|
|
|
|
2002-05-29 00:57:53 +08:00
|
|
|
# PGAC_CHECK_PERL_CONFIG(NAME)
|
|
|
|
|
# ----------------------------
|
|
|
|
|
AC_DEFUN([PGAC_CHECK_PERL_CONFIG],
|
|
|
|
|
[AC_REQUIRE([PGAC_PATH_PERL])
|
|
|
|
|
AC_MSG_CHECKING([for Perl $1])
|
|
|
|
|
perl_$1=`$PERL -MConfig -e 'print $Config{$1}'`
|
2013-01-10 06:49:23 +08:00
|
|
|
test "$PORTNAME" = "win32" && perl_$1=`echo $perl_$1 | sed 's,\\\\,/,g'`
|
2002-05-29 00:57:53 +08:00
|
|
|
AC_SUBST(perl_$1)dnl
|
|
|
|
|
AC_MSG_RESULT([$perl_$1])])
|
2001-08-27 06:28:04 +08:00
|
|
|
|
|
|
|
|
|
2002-05-29 00:57:53 +08:00
|
|
|
# PGAC_CHECK_PERL_CONFIGS(NAMES)
|
|
|
|
|
# ------------------------------
|
|
|
|
|
AC_DEFUN([PGAC_CHECK_PERL_CONFIGS],
|
|
|
|
|
[m4_foreach([pgac_item], [$1], [PGAC_CHECK_PERL_CONFIG(pgac_item)])])
|
2001-08-27 06:28:04 +08:00
|
|
|
|
2002-05-29 00:57:53 +08:00
|
|
|
|
PL/Perl portability fix: absorb relevant -D switches from Perl.
The Perl documentation is very clear that stuff calling libperl should
be built with the compiler switches shown by Perl's $Config{ccflags}.
We'd been ignoring that up to now, and mostly getting away with it,
but recent Perl versions contain ABI compatibility cross-checks that
fail on some builds because of this omission. In particular the
sizeof(PerlInterpreter) can come out different due to some fields being
added or removed; which means we have a live ABI hazard that we'd better
fix rather than continuing to sweep it under the rug.
However, it still seems like a bad idea to just absorb $Config{ccflags}
verbatim. In some environments Perl was built with a different compiler
that doesn't even use the same switch syntax. -D switch syntax is pretty
universal though, and absorbing Perl's -D switches really ought to be
enough to fix the problem.
Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on
platforms where they're relevant. Adopting those seems dangerous too.
It's unclear whether a build wherein Perl and Postgres have different ideas
of sizeof(off_t) etc would work, or whether anyone would care about making
it work. But it's dead certain that having different stdio ABIs in
core Postgres and PL/Perl will not work; we've seen that movie before.
Therefore, let's also ignore -D switches for symbols beginning with
underscore. The symbols that we actually need to import should be the ones
mentioned in perl.h's PL_bincompat_options stanza, and none of those start
with underscore, so this seems likely to work. (If it turns out not to
work everywhere, we could consider intersecting the symbols mentioned in
PL_bincompat_options with the -D switches. But that will be much more
complicated, so let's try this way first.)
This will need to be back-patched, but first let's see what the
buildfarm makes of it.
Ashutosh Sharma, some adjustments by me
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-29 02:25:28 +08:00
|
|
|
# PGAC_CHECK_PERL_EMBED_CCFLAGS
|
|
|
|
|
# -----------------------------
|
2017-12-09 10:06:05 +08:00
|
|
|
# We selectively extract stuff from $Config{ccflags}. For debugging purposes,
|
|
|
|
|
# let's have the configure output report the raw ccflags value as well as the
|
|
|
|
|
# set of flags we chose to adopt. We don't really need anything except -D
|
|
|
|
|
# switches, and other sorts of compiler switches can actively break things if
|
|
|
|
|
# Perl was compiled with a different compiler. Moreover, although Perl likes
|
|
|
|
|
# to put stuff like -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64 here, it
|
|
|
|
|
# would be fatal to try to compile PL/Perl to a different libc ABI than core
|
|
|
|
|
# Postgres uses. The available information says that most symbols that affect
|
|
|
|
|
# Perl's own ABI begin with letters, so it's almost sufficient to adopt -D
|
2023-12-20 08:44:37 +08:00
|
|
|
# switches for symbols not beginning with underscore.
|
|
|
|
|
|
|
|
|
|
# Some exceptions are the Windows-specific -D_USE_32BIT_TIME_T and
|
|
|
|
|
# -D__MINGW_USE_VC2005_COMPAT. To be exact, Windows offers several 32-bit ABIs.
|
|
|
|
|
# Perl is sensitive to sizeof(time_t), one of the ABI dimensions. PostgreSQL
|
|
|
|
|
# doesn't support building with pre-MSVC-2005 compilers, but it does support
|
|
|
|
|
# linking to Perl built with such a compiler. MSVC-built Perl 5.13.4 and
|
|
|
|
|
# later report -D_USE_32BIT_TIME_T in $Config{ccflags} if applicable, but
|
|
|
|
|
# MinGW-built Perl never reports -D_USE_32BIT_TIME_T despite typically needing
|
|
|
|
|
# it.
|
|
|
|
|
#
|
2017-12-09 10:06:05 +08:00
|
|
|
# Consequently, we don't support using MinGW to link to MSVC-built Perl. As
|
|
|
|
|
# of 2017, all supported ActivePerl and Strawberry Perl are MinGW-built. If
|
|
|
|
|
# that changes or an MSVC-built Perl distribution becomes prominent, we can
|
|
|
|
|
# revisit this limitation.
|
PL/Perl portability fix: absorb relevant -D switches from Perl.
The Perl documentation is very clear that stuff calling libperl should
be built with the compiler switches shown by Perl's $Config{ccflags}.
We'd been ignoring that up to now, and mostly getting away with it,
but recent Perl versions contain ABI compatibility cross-checks that
fail on some builds because of this omission. In particular the
sizeof(PerlInterpreter) can come out different due to some fields being
added or removed; which means we have a live ABI hazard that we'd better
fix rather than continuing to sweep it under the rug.
However, it still seems like a bad idea to just absorb $Config{ccflags}
verbatim. In some environments Perl was built with a different compiler
that doesn't even use the same switch syntax. -D switch syntax is pretty
universal though, and absorbing Perl's -D switches really ought to be
enough to fix the problem.
Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on
platforms where they're relevant. Adopting those seems dangerous too.
It's unclear whether a build wherein Perl and Postgres have different ideas
of sizeof(off_t) etc would work, or whether anyone would care about making
it work. But it's dead certain that having different stdio ABIs in
core Postgres and PL/Perl will not work; we've seen that movie before.
Therefore, let's also ignore -D switches for symbols beginning with
underscore. The symbols that we actually need to import should be the ones
mentioned in perl.h's PL_bincompat_options stanza, and none of those start
with underscore, so this seems likely to work. (If it turns out not to
work everywhere, we could consider intersecting the symbols mentioned in
PL_bincompat_options with the -D switches. But that will be much more
complicated, so let's try this way first.)
This will need to be back-patched, but first let's see what the
buildfarm makes of it.
Ashutosh Sharma, some adjustments by me
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-29 02:25:28 +08:00
|
|
|
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}']`
|
|
|
|
|
AC_MSG_RESULT([$perl_ccflags])
|
|
|
|
|
AC_MSG_CHECKING([for CFLAGS to compile embedded Perl])
|
Absorb -D_USE_32BIT_TIME_T switch from Perl, if relevant.
Commit 3c163a7fc's original choice to ignore all #define symbols whose
names begin with underscore turns out to be too simplistic. On Windows,
some Perl installations are built with -D_USE_32BIT_TIME_T, and we must
absorb that or we get the wrong result for sizeof(PerlInterpreter).
This effectively re-reverts commit ef58b87df, which injected that symbol
in a hacky way, making it apply to all of Postgres not just PL/Perl.
More significantly, it did so on *all* 32-bit Windows builds, even when
the Perl build to be used did not select this option; so that it fails
to work properly with some newer Perl builds.
By making this change, we would be introducing an ABI break in 32-bit
Windows builds; but fortunately we have not used type time_t in any
exported Postgres APIs in a long time. So it should be OK, both for
PL/Perl itself and for third-party extensions, if an extension library
is built with a different _USE_32BIT_TIME_T setting than the core code.
Patch by me, based on research by Ashutosh Sharma and Robert Haas.
Back-patch to all supported branches, as commit 3c163a7fc was.
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-08-14 23:48:59 +08:00
|
|
|
perl_embed_ccflags=`$PERL -MConfig -e ['foreach $f (split(" ",$Config{ccflags})) {print $f, " " if ($f =~ /^-D[^_]/ || $f =~ /^-D_USE_32BIT_TIME_T/)}']`
|
PL/Perl portability fix: absorb relevant -D switches from Perl.
The Perl documentation is very clear that stuff calling libperl should
be built with the compiler switches shown by Perl's $Config{ccflags}.
We'd been ignoring that up to now, and mostly getting away with it,
but recent Perl versions contain ABI compatibility cross-checks that
fail on some builds because of this omission. In particular the
sizeof(PerlInterpreter) can come out different due to some fields being
added or removed; which means we have a live ABI hazard that we'd better
fix rather than continuing to sweep it under the rug.
However, it still seems like a bad idea to just absorb $Config{ccflags}
verbatim. In some environments Perl was built with a different compiler
that doesn't even use the same switch syntax. -D switch syntax is pretty
universal though, and absorbing Perl's -D switches really ought to be
enough to fix the problem.
Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on
platforms where they're relevant. Adopting those seems dangerous too.
It's unclear whether a build wherein Perl and Postgres have different ideas
of sizeof(off_t) etc would work, or whether anyone would care about making
it work. But it's dead certain that having different stdio ABIs in
core Postgres and PL/Perl will not work; we've seen that movie before.
Therefore, let's also ignore -D switches for symbols beginning with
underscore. The symbols that we actually need to import should be the ones
mentioned in perl.h's PL_bincompat_options stanza, and none of those start
with underscore, so this seems likely to work. (If it turns out not to
work everywhere, we could consider intersecting the symbols mentioned in
PL_bincompat_options with the -D switches. But that will be much more
complicated, so let's try this way first.)
This will need to be back-patched, but first let's see what the
buildfarm makes of it.
Ashutosh Sharma, some adjustments by me
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-29 02:25:28 +08:00
|
|
|
AC_SUBST(perl_embed_ccflags)dnl
|
|
|
|
|
AC_MSG_RESULT([$perl_embed_ccflags])
|
|
|
|
|
])# PGAC_CHECK_PERL_EMBED_CCFLAGS
|
|
|
|
|
|
|
|
|
|
|
2002-05-29 00:57:53 +08:00
|
|
|
# PGAC_CHECK_PERL_EMBED_LDFLAGS
|
|
|
|
|
# -----------------------------
|
2009-09-09 02:15:55 +08:00
|
|
|
# We are after Embed's ldopts, but without the subset mentioned in
|
2022-08-23 22:00:38 +08:00
|
|
|
# Config's ccdlflags and ldflags. (Those are the choices of those who
|
|
|
|
|
# built the Perl installation, which are not necessarily appropriate
|
|
|
|
|
# for building PostgreSQL.)
|
2002-05-29 00:57:53 +08:00
|
|
|
AC_DEFUN([PGAC_CHECK_PERL_EMBED_LDFLAGS],
|
|
|
|
|
[AC_REQUIRE([PGAC_PATH_PERL])
|
|
|
|
|
AC_MSG_CHECKING(for flags to link embedded Perl)
|
2013-01-10 06:49:23 +08:00
|
|
|
if test "$PORTNAME" = "win32" ; then
|
2017-11-24 12:22:04 +08:00
|
|
|
perl_lib=`basename $perl_archlibexp/CORE/perl[[5-9]]*.lib .lib`
|
|
|
|
|
if test -e "$perl_archlibexp/CORE/$perl_lib.lib"; then
|
|
|
|
|
perl_embed_ldflags="-L$perl_archlibexp/CORE -l$perl_lib"
|
|
|
|
|
else
|
|
|
|
|
perl_lib=`basename $perl_archlibexp/CORE/libperl[[5-9]]*.a .a | sed 's/^lib//'`
|
|
|
|
|
if test -e "$perl_archlibexp/CORE/lib$perl_lib.a"; then
|
|
|
|
|
perl_embed_ldflags="-L$perl_archlibexp/CORE -l$perl_lib"
|
|
|
|
|
fi
|
|
|
|
|
fi
|
2013-01-10 06:49:23 +08:00
|
|
|
else
|
2017-11-24 12:22:04 +08:00
|
|
|
pgac_tmp1=`$PERL -MExtUtils::Embed -e ldopts`
|
2022-08-23 22:00:38 +08:00
|
|
|
pgac_tmp2=`$PERL -MConfig -e 'print "$Config{ccdlflags} $Config{ldflags}"'`
|
|
|
|
|
perl_embed_ldflags=`echo X"$pgac_tmp1" | sed -e "s/^X//" -e "s%$pgac_tmp2%%"`
|
2013-01-10 06:49:23 +08:00
|
|
|
fi
|
2002-05-29 00:57:53 +08:00
|
|
|
AC_SUBST(perl_embed_ldflags)dnl
|
2008-11-12 08:00:05 +08:00
|
|
|
if test -z "$perl_embed_ldflags" ; then
|
|
|
|
|
AC_MSG_RESULT(no)
|
|
|
|
|
AC_MSG_ERROR([could not determine flags for linking embedded Perl.
|
|
|
|
|
This probably means that ExtUtils::Embed or ExtUtils::MakeMaker is not
|
|
|
|
|
installed.])
|
|
|
|
|
else
|
|
|
|
|
AC_MSG_RESULT([$perl_embed_ldflags])
|
|
|
|
|
fi
|
|
|
|
|
])# PGAC_CHECK_PERL_EMBED_LDFLAGS
|
