18 Commits (12a53c732cedf83f70106b5605a5003c2000d7f4)

Author	SHA1	Message	Date
Noah Misch	65a00f3035	MSVC: Test whether 32-bit Perl needs -D_USE_32BIT_TIME_T. ... Commits 5a5c2feca3 and b5178c5d08 introduced support for modern MSVC-built, 32-bit Perl, but they broke use of MinGW-built, 32-bit Perl distributions like Strawberry Perl and modern ActivePerl. Perl has no robust means to report whether it expects a -D_USE_32BIT_TIME_T ABI, so test this. Back-patch to 9.3 (all supported versions). The chief alternative was a heuristic of adding -D_USE_32BIT_TIME_T when $Config{gccversion} is nonempty. That banks on every gcc-built Perl using the same ABI. gcc could change its default ABI the way MSVC once did, and one could build Perl with gcc and the non-default ABI. The GNU make build system could benefit from a similar test, without which it does not support MSVC-built Perl. For now, just add a comment. Most users taking the special step of building Perl with MSVC probably build PostgreSQL with MSVC. Discussion: https://postgr.es/m/20171130041441.GA3161526@rfd.leadboat.com	8 years ago
Noah Misch	84c4313c6f	Support linking with MinGW-built Perl. ... This is necessary for ActivePerl 5.18 onwards and for Strawberry Perl. It is not sufficient for 32-bit builds with newer Visual Studio; these fail with error LINK2026. Back-patch to 9.3 (all supported versions). Reported by Victor Wagner. Discussion: https://postgr.es/m/20160326154321.7754ab8f@wagner.wagner.home	8 years ago
Tom Lane	5a5c2feca3	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	8 years ago
Tom Lane	b21c569cea	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	8 years ago
Tom Lane	3c163a7fc7	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	8 years ago
Tom Lane	7d7b129277	Fix configure's incorrect version tests for flex and perl. ... awk's equality-comparison operator is "==" not "=". We got this right in many places, but not in configure's checks for supported version numbers of flex and perl. It hadn't been noticed because unsupported versions are so old as to be basically extinct in the wild, and because the only consequence is whether or not a WARNING flies by during configure. Daniel Gustafsson noted the problem with respect to the test for flex, I found the other by reviewing other awk calls.	9 years ago
Andrew Dunstan	7fb97ecd13	Detect Windows perl linkage parameters in configure script. ... This means we can now construct a configure test for the library presence. Previously these parameters were only figured out at build time in plperl's GnuMakefile.	13 years ago
Tom Lane	651377933e	Fix remaining stray references to CVS. ... These are just cosmetic and don't seem worth back-patching far. I put them into 9.0 just because it was trivial to do so.	15 years ago
Magnus Hagander	9f2e211386	Remove cvs keywords from all files.	15 years ago
Tom Lane	dc43e2f540	Fix configure's regexp for extracting the Perl version number from perl -v ... output. Per bug #5339, Perl 5.11 has changed the format of that output enough to break the previous coding. Alex Hunsaker	16 years ago
Bruce Momjian	b4689bfb00	Revert configure warning to use "official distribution".	16 years ago
Bruce Momjian	6a0b6421e2	Use the term "bundled distribution" instead of "official distribution" in ... configure warnings.	16 years ago
Tom Lane	55233c3382	Make configure check the version of Perl we're building with, and reject ... versions < 5.8. Also, if there's no Perl, emit a warning informing the user that he won't be able to build from a CVS pull. This is exactly the same treatment we give Bison and Perl, and for the same reasons.	16 years ago
Tom Lane	d69a419e68	Remove any -arch switches given in ExtUtils::Embed's ldopts from our ... perl_embed_ldflags setting. On OS X it seems that ExtUtils::Embed is trying to force a universal binary to be built, but you need to specify that a lot further upstream if you want Postgres built that way; the only result of including -arch in perl_embed_ldflags is some warnings at the plperl.so link step. Per my complaint and Jan Otto's suggestion.	16 years ago
Andrew Dunstan	466368b8d0	Detect and error out on inability to get proper linkage information required for plperl, usually due to absence of perl ExtUtils::Embed module. Backpatch as far as 8.1.	17 years ago
PostgreSQL Daemon	969685ad44	$Header: -> $PostgreSQL Changes ...	22 years ago
Peter Eisentraut	7662419f1b	Change PL/Perl and Pg interface build to use configured compiler and ... Makefile.shlib system, not MakeMaker.	24 years ago
Peter Eisentraut	ef7152f99b	Put the right runpath to libpq into the Perl module shared object on more ... platforms and without relinking. Also support VPATH builds and DESTDIR installs. One hopes.	24 years ago