Commit Graph

165 Commits

Author SHA1 Message Date
Peter Eisentraut 1933ae629e Add PostgreSQL home page to --help output
Per emerging standard in GNU programs and elsewhere.  Autoconf already
has support for specifying a home page, so we can just that.

Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/flat/8d389c5f-7fb5-8e48-9a4a-68cec44786fa%402ndquadrant.com
2020-02-28 13:12:21 +01:00
Peter Eisentraut ea9e06ac66 Clean up MinGW def file generation
There were some leftovers from ancient ad-hoc ways to build on
Windows, prior to the standardization on MSVC and MinGW.  We don't
need to build a lib$(NAME)ddll.def (debug build, as opposed to
lib$(NAME)dll.def) for MinGW, since nothing uses that.  We also don't
need to build the regular .def file during distprep, since the MinGW
build environment is perfectly capable of creating that normally at
build time.

Discussion: https://www.postgresql.org/message-id/flat/0f9db9f8-47b8-a48b-6ccc-15b22b412316%402ndquadrant.com
2019-10-20 10:19:13 +02:00
Peter Eisentraut c72f9b9502 Remove support for non-ELF BSD systems
This is long obsolete.

Discussion: https://www.postgresql.org/message-id/8eacdc0d-123f-dbca-bacf-0a68766a4889@2ndquadrant.com
2019-07-01 23:56:20 +01:00
Tom Lane 826eff57c4 Ensure static libraries have correct mod time even if ranlib messes it up.
In at least Apple's version of ranlib, the output file is updated to have
a mod time equal to the max of the timestamps of its components, and that
data only has seconds precision.  On a filesystem with sub-second file
timestamp precision --- say, APFS --- this can result in the finished
static library appearing older than its input files, which causes useless
rebuilds and possible outright failures in parallel makes.

We've only seen this reported in the field from people using Apple's
ranlib with a non-Apple make, because Apple's make doesn't know about
sub-second timestamps either so it doesn't decide rebuilds are needed.
But Apple's ranlib presumably shares code with at least some BSDen,
so it's not that unlikely that the same problem could arise elsewhere.

To fix, just "touch" the output file after ranlib finishes.

We seem to need this in only one place.  There are other calls of
ranlib in our makefiles, but they are working on intermediate files
whose timestamps are not actually important, or else on an installed
static library for which sub-second timestamp precision is unlikely
to matter either.  (Also, so far as I can tell, Apple's ranlib doesn't
mess up the file timestamp in the latter usage anyhow.)

In passing, change "ranlib" to "$(RANLIB)" in one place that was
bypassing the make macro for no good reason.

Per bug #15525 from Jack Kelly (via Alyssa Ross).
Back-patch to all supported branches.

Discussion: https://postgr.es/m/15525-a30da084f17a1faa@postgresql.org
2018-11-29 15:53:44 -05:00
Andrew Dunstan a33245a853 Don't build static libraries on Cygwin
Cygwin has been building and linking against static libraries. Although
a bug this has been relatively harmless until now, when this has caused
errors due to changes in the way we build certain libraries. So this
patch makes things work the way we always intended, namely that we would
link against the dynamic libraries (cygpq.dll etc.) and just not build
the static libraries. The downstream packagers have been doing this for
some time, so this just aligns with their practice.

Extracted from a patch by Marco Atzeri, with a suggestion from Tom Lane.

Discussion: https://postgr.es/m/1056.1538235347@sss.pgh.pa.us
2018-10-02 16:46:57 -04:00
Tom Lane 4fa3741d1c Use -Bsymbolic for shared libraries on HP-UX and Solaris.
These platforms are also subject to the mis-linking problem addressed
in commit e3d77ea6b.  It's not clear whether we could solve it with
a solution equivalent to GNU ld's version scripts, but -Bsymbolic
appears to fix it, so let's use that.

Like the previous commit, back-patch as far as v10.

Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org
2018-09-10 22:22:12 -04:00
Tom Lane e3d77ea6b4 Prevent mis-linking of src/port and src/common functions on *BSD.
On ELF-based platforms (and maybe others?) it's possible for a shared
library, when dynamically loaded into the backend, to call the backend
versions of src/port and src/common functions rather than the frontend
versions that are actually linked into the shlib.  This is the cause
of bug #15367 from Jeremy Evans, and is likely to lead to more problems
in future; it's accidental that we've failed to notice any bad effects
up to now.

The recommended way to fix this on ELF-based platforms is to use a
linker "version script" that makes the shlib's versions of the functions
local.  (Apparently, -Bsymbolic would fix it as well, but with other
side effects that we don't want.)  Doing so has the additional benefit
that we can make sure the shlib only exposes the symbols that are meant
to be part of its API, and not ones that are just for cross-file
references within the shlib.  So we'd already been using a version
script for libpq on popular platforms, but it's now apparent that it's
necessary for correctness on every ELF-based platform.

Hence, add appropriate logic to the openbsd, freebsd, and netbsd stanzas
of Makefile.shlib; this is just a copy-and-paste from the linux stanza.
There may be additional work to do if commit ed0cdf0e0 reveals that the
problem exists elsewhere, but this is all that is known to be needed
right now.

Back-patch to v10 where SCRAM support came in.  The problem is ancient,
but analysis suggests that there were no really severe consequences
in older branches.  Hence, I won't take the risk of such a large change
in the build process for older branches.

In passing, remove a rather opaque comment about -Bsymbolic; I don't
think it's very on-point about why we don't use that, if indeed that's
what it's talking about at all.

Patch by me; thanks to Andrew Gierth for helping to diagnose the problem,
and for additional testing.

Discussion: https://postgr.es/m/153626613985.23143.4743626885618266803@wrigleys.postgresql.org
2018-09-09 15:17:01 -04:00
Tom Lane dddfc4cb2e Prevent accidental linking of system-supplied copies of libpq.so etc.
We were being careless in some places about the order of -L switches in
link command lines, such that -L switches referring to external directories
could come before those referring to directories within the build tree.
This made it possible to accidentally link a system-supplied library, for
example /usr/lib/libpq.so, in place of the one built in the build tree.
Hilarity ensued, the more so the older the system-supplied library is.

To fix, break LDFLAGS into two parts, a sub-variable LDFLAGS_INTERNAL
and the main LDFLAGS variable, both of which are "recursively expanded"
so that they can be incrementally adjusted by different makefiles.
Establish a policy that -L switches for directories in the build tree
must always be added to LDFLAGS_INTERNAL, while -L switches for external
directories must always be added to LDFLAGS.  This is sufficient to
ensure a safe search order.  For simplicity, we typically also put -l
switches for the respective libraries into those same variables.
(Traditional make usage would have us put -l switches into LIBS, but
cleaning that up is a project for another day, as there's no clear
need for it.)

This turns out to also require separating SHLIB_LINK into two variables,
SHLIB_LINK and SHLIB_LINK_INTERNAL, with a similar rule about which
switches go into which variable.  And likewise for PG_LIBS.

Although this change might appear to affect external users of pgxs.mk,
I think it doesn't; they shouldn't have any need to touch the _INTERNAL
variables.

In passing, tweak src/common/Makefile so that the value of CPPFLAGS
recorded in pg_config lacks "-DFRONTEND" and the recorded value of
LDFLAGS lacks "-L../../../src/common".  Both of those things are
mistakes, apparently introduced during prior code rearrangements,
as old versions of pg_config don't print them.  In general we don't
want anything that's specific to the src/common subdirectory to
appear in those outputs.

This is certainly a bug fix, but in view of the lack of field
complaints, I'm unsure whether it's worth the risk of back-patching.
In any case it seems wise to see what the buildfarm makes of it first.

Discussion: https://postgr.es/m/25214.1522604295@sss.pgh.pa.us
2018-04-03 16:26:05 -04:00
Tom Lane 4b538727e2 Fix make rules that generate multiple output files.
For years, our makefiles have correctly observed that "there is no correct
way to write a rule that generates two files".  However, what we did is to
provide empty rules that "generate" the secondary output files from the
primary one, and that's not right either.  Depending on the details of
the creating process, the primary file might end up timestamped later than
one or more secondary files, causing subsequent make runs to consider the
secondary file(s) out of date.  That's harmless in a plain build, since
make will just re-execute the empty rule and nothing happens.  But it's
fatal in a VPATH build, since make will expect the secondary file to be
rebuilt in the build directory.  This would manifest as "file not found"
failures during VPATH builds from tarballs, if we were ever unlucky enough
to ship a tarball with apparently out-of-date secondary files.  (It's not
clear whether that has ever actually happened, but it definitely could.)

To ensure that secondary output files have timestamps >= their primary's,
change our makefile convention to be that we provide a "touch $@" action
not an empty rule.  Also, make sure that this rule actually gets invoked
during a distprep run, else the hazard remains.

It's been like this a long time, so back-patch to all supported branches.

In HEAD, I skipped the changes in src/backend/catalog/Makefile, because
those rules are due to get replaced soon in the bootstrap data format
patch, and there seems no need to create a merge issue for that patch.
If for some reason we fail to land that patch in v11, we'll need to
back-fill the changes in that one makefile from v10.

Discussion: https://postgr.es/m/18556.1521668179@sss.pgh.pa.us
2018-03-23 13:46:00 -04:00
Andres Freund 6869b4f258 Add C++ support to configure.
This is an optional dependency. It'll be used for the upcoming LLVM
based just in time compilation support, which needs to wrap a few LLVM
C++ APIs so they're accessible from C..

For now test for C++ compilers unconditionally, without failing if not
present, to ensure wide buildfarm coverage. If we're bothered by the
additional test times (which are quite short) or verbosity, we can
later make the tests conditional on --with-llvm.

Author: Andres Freund
Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
2018-03-20 15:48:48 -07:00
Magnus Hagander 6da56f3f84 Remove support for bcc and msvc standalone libpq builds
This removes the support for building just libpq using Borland C++ or
Visual C++. This has not worked properly for years, and given the number
of complaints it's clearly not worth the maintenance burden.

Building libpq using the standard MSVC build system is of course still
supported, along with mingw.
2017-04-11 15:22:21 +02:00
Heikki Linnakangas 181bdb90ba Fix typos in comments.
Backpatch to all supported versions, where applicable, to make backpatching
of future fixes go more smoothly.

Josh Soref

Discussion: https://www.postgresql.org/message-id/CACZqfqCf+5qRztLPgmmosr-B0Ye4srWzzw_mo4c_8_B_mtjmJQ@mail.gmail.com
2017-02-06 11:33:58 +02:00
Tom Lane d2ab117616 Fix cross-shlib linking in temporary installs on HPUX 10.
Turns out this has been broken for years and we'd not noticed.  The one
case that was getting exercised in the buildfarm, or probably anywhere
else, was postgres_fdw.sl's reference to libpq.sl; and it turns out that
that was always going to libpq.sl in the actual installation directory
not the temporary install.  We'd not noticed because the buildfarm script
does "make install" before it tests contrib.  However, the recent addition
of a logical-replication test to the core regression scripts resulted in
trying to use libpqwalreceiver.sl before "make install" happens, and that
failed for lack of finding libpq.sl, as shown by failures on buildfarm
members gaur and pademelon.

There are two changes needed to fix it: the magic environment variable to
specify shlib search path at runtime is SHLIB_PATH not LD_LIBRARY_PATH,
and the shlib link command needs to specify the +s switch else the library
will not honor SHLIB_PATH.

I'm not quite sure why buildfarm members anole and gharial (HPUX 11) didn't
show the same failure.  Consulting man pages on the web says that HPUX 11
honors both LD_LIBRARY_PATH and SHLIB_PATH, which would explain half of it,
and the rather confusing wording I've been able to find suggests that +s
might effectively be the default in HPUX 11.  But it seems at least as
likely that there's just a libpq.so installed in /usr/lib on that machine;
as long as it's not too ancient, that would satisfy the test.  In any case
I do not think this patch will break HPUX 11.

At the moment I don't see a need to back-patch this, since it only matters
for testing purposes, not to mention that HPUX 10 is probably dead in the
real world anyway.
2017-01-21 15:15:39 -05:00
Tom Lane 2b860f52ed Remove "sco" and "unixware" ports.
SCO OpenServer and SCO UnixWare are more or less dead platforms.
We have never had a buildfarm member testing the "sco" port, and
the last "unixware" member was last heard from in 2012, so it's
fair to doubt that the code even compiles anymore on either one.
Remove both ports.  We can always undo this if someone shows up
with an interest in maintaining and testing these platforms.

Discussion: <17177.1476136994@sss.pgh.pa.us>
2016-10-11 11:26:04 -04:00
Tom Lane bfe2e84781 Remove -Wl,-undefined,dynamic_lookup in macOS build.
We don't need this anymore, and it prevents build-time error checking
that's usually good to have, so remove it.  Undoes one change of commit
cac765820.

Unfortunately, it's much harder to get a similar effect on other common
platforms, because we don't want the linker to throw errors for symbols
that will be resolved in the core backend.  Only macOS and AIX expect the
core backend executable to be available while linking loadable modules,
so only these platforms can usefully throw errors for unresolved symbols
at link time.

Discussion: <2652.1475512158@sss.pgh.pa.us>
2016-10-05 23:03:55 -04:00
Tom Lane ea046f08d1 Fix misstatement in comment in Makefile.shlib.
There is no need for "all: all-lib" to be placed before inclusion of
Makefile.shlib.  Makefile.global is what ensures that "all" is the
default target, and we already document that that has to be included
first.  Per comment from Pavel Raiskup.

Discussion: <1925924.izSMJEZO3x@unused-4-107.brq.redhat.com>
2016-10-01 13:45:16 -04:00
Tom Lane da6c4f6ca8 Refer to OS X as "macOS", except for the port name which is still "darwin".
We weren't terribly consistent about whether to call Apple's OS "OS X"
or "Mac OS X", and the former is probably confusing to people who aren't
Apple users.  Now that Apple has rebranded it "macOS", follow their lead
to establish a consistent naming pattern.  Also, avoid the use of the
ancient project name "Darwin", except as the port code name which does not
seem desirable to change.  (In short, this patch touches documentation and
comments, but no actual code.)

I didn't touch contrib/start-scripts/osx/, either.  I suspect those are
obsolete and due for a rewrite, anyway.

I dithered about whether to apply this edit to old release notes, but
those were responsible for quite a lot of the inconsistencies, so I ended
up changing them too.  Anyway, Apple's being ahistorical about this,
so why shouldn't we be?
2016-09-25 15:40:57 -04:00
Noah Misch e8564ef034 Make the AIX case of Makefile.shlib safe for parallel make.
Use our typical approach, from src/backend/parser.  Back-patch to 9.1
(all supported versions).
2016-07-23 20:30:03 -04:00
Noah Misch 7193436744 AIX: Link TRANSFORM modules with their dependencies.
The result closely resembles linking of these modules for the "win32"
port.  Augment the $(exports_file) header so the file is also usable as
an import file.  Unfortunately, relocating an AIX installation will now
require adding $(pkglibdir) to LD_LIBRARY_PATH.  Back-patch to 9.5,
where the modules were introduced.
2015-07-15 21:00:26 -04:00
Peter Eisentraut cac7658205 Add transforms feature
This provides a mechanism for specifying conversions between SQL data
types and procedural languages.  As examples, there are transforms
for hstore and ltree for PL/Perl and PL/Python.

reviews by Pavel Stěhule and Andres Freund
2015-04-26 10:33:14 -04:00
Noah Misch 424793fa5d Unlink static libraries before rebuilding them.
When the library already exists in the build directory, "ar" preserves
members not named on its command line.  This mattered when, for example,
a "configure" rerun dropped a file from $(LIBOBJS).  libpgport carried
the obsolete member until "make clean".  Back-patch to 9.0 (all
supported versions).
2015-03-01 13:05:23 -05:00
Peter Eisentraut cb4a3b0410 Install shared libraries also in bin on cygwin, mingw
This was previously only done for libpq, not it's done for all shared
libraries.

Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2015-01-18 22:36:40 -05:00
Noah Misch c40212baf6 Clarify .def file comments. 2014-11-02 21:43:33 -05:00
Noah Misch c0e190365b MinGW: Include .dll extension in .def file LIBRARY commands.
Newer toolchains append the extension implicitly if missing, but
buildfarm member narwhal (gcc 3.4.2, ld 2.15.91 20040904) does not.
This affects most core libraries having an exports.txt file, namely
libpq and the ECPG support libraries.  On Windows Server 2003, Windows
API functions that load and unload DLLs internally will mistakenly
unload a libpq whose DLL header reports "LIBPQ" instead of "LIBPQ.dll".
When, subsequently, control would return to libpq, the backend crashes.
Back-patch to 9.4, like commit 846e91e022.
Before that commit, we used a different linking technique that yielded
"libpq.dll" in the DLL header.

Commit 53566fc094 worked around this by
eliminating a call to a function that loads and unloads DLLs internally.
That commit is no longer necessary for correctness, but its improving
consistency with the MSVC build remains valid.
2014-10-27 19:59:39 -04:00
Noah Misch 284590e416 MinGW: Use -static-libgcc when linking a DLL.
When commit 846e91e022 switched the linker
driver from dlltool/dllwrap to gcc, it became possible for linking to
choose shared libgcc.  Backends having loaded a module dynamically
linked to libgcc can exit abnormally, which the postmaster treats like a
crash.  Resume use of static libgcc exclusively, like 9.3 and earlier.
Back-patch to 9.4.
2014-10-21 22:55:47 -04:00
Andres Freund a6d488cb53 Remove Alpha and Tru64 support.
Support for running postgres on Alpha hasn't been tested for a long
while. Due to Alpha's uniquely lax cache coherency model it's a hard
to develop for platform (especially blindly!) and thought to be
unlikely to currently work correctly.

As Alpha is the only supported architecture for Tru64 drop support for
it as well. Tru64's support has ended 2012 and it has been in
maintenance-only mode for much longer.

Also remove stray references to __ksr__ and ultrix defines.
2014-06-28 21:46:15 +02:00
Tom Lane b23fd2d8b3 Tweak position of $(DLL_DEFFILE) in shared-library link commands.
Reading the GNU ld man page suggests that this is order-sensitive
and should go in front of library references.  Correction to commit
846e91e022.
2014-02-12 11:22:23 -05:00
Tom Lane 846e91e022 Get rid of use of dlltool in Mingw builds.
We are almost completely out of the dlltool game, if this works.

Hiroshi Inoue
2014-02-11 12:56:20 -05:00
Andrew Dunstan c8158a2eed fix whitespace 2014-02-01 16:30:26 -05:00
Andrew Dunstan 7e1531a450 Don't use deprecated dllwrap on Cygwin.
The preferred method is to use "cc -shared", and this allows binaries
to be rebased if required, unlike dllwrap.

Backpatch to 9.0 where we have buildfarm coverage.

There are still some issues with Cygwin, especially modern Cygwin, but
this helps us get closer to good support.

Marco Atzeri.
2014-02-01 16:08:33 -05:00
Robert Haas ea91a6be89 Remove IRIX port.
Development of IRIX has been discontinued, and support is scheduled
to end in December of 2013.  Therefore, there will be no supported
versions of this operating system by the time PostgreSQL 9.4 is
released.  Furthermore, we have no maintainer for this platform.
2013-10-18 08:14:21 -04:00
Peter Eisentraut 64f890905f Add pkg-config files for libpq and ecpg libraries
This will hopefully be easier to use than pg_config for users who are
already used to the pkg-config interface.  It also works better for
multi-arch installations.

reviewed by Tom Lane
2013-03-31 16:58:40 -04:00
Bruce Momjian 381a9ed66d Remove configure flag --disable-shared, as it is no longer used by any
port.  The last use was QNX, per Peter Eisentraut.
2012-08-30 16:26:53 -04:00
Bruce Momjian ebcaa5fcde Remove BSD/OS (BSDi) port. There are no known users upgrading to
Postgres 9.2, and perhaps no existing users either.
2012-05-03 10:58:44 -04:00
Peter Eisentraut f2f9439fbf Remove dead ports
Remove the following ports:

- dgux
- nextstep
- sunos4
- svr4
- ultrix4
- univel

These are obsolete and not worth rescuing.  In most cases, there is
circumstantial evidence that they wouldn't work anymore anyway.
2012-05-01 22:11:12 +03:00
Tom Lane 1568fa75bc Use single quotes in preference to double quotes for protecting pathnames.
Per recommendation from Peter.  Neither choice is bulletproof, but this
is the existing style and it does help prevent unexpected environment
variable substitution.
2011-06-15 21:45:23 -04:00
Tom Lane a61b6b7d18 Fix assorted issues with build and install paths containing spaces.
Apparently there is no buildfarm critter exercising this case after all,
because it fails in several places.  With this patch, build, install,
check-world, and installcheck-world pass for me on OS X.
2011-06-14 16:40:35 -04:00
Peter Eisentraut fc946c39ae Remove useless whitespace at end of lines 2010-11-23 22:34:55 +02:00
Peter Eisentraut 19e231bbda Improved parallel make support
Replace for loops in makefiles with proper dependencies.  Parallel
make can now span across directories.  Also, make -k and make -q work
properly.

GNU make 3.80 or newer is now required.
2010-11-12 22:15:16 +02:00
Magnus Hagander 9f2e211386 Remove cvs keywords from all files. 2010-09-20 22:08:53 +02:00
Tom Lane 8307b092b7 Still more third thoughts: when linking shared libraries, LDFLAGS probably
needs to appear before anything placed in SHLIB_LINK.  This is because
SHLIB_LINK is typically a subset of LIBS, and LIBS has to appear after
LDFLAGS on platforms that are sensitive to the relative order of -L and -l
switches.
2010-07-06 03:55:33 +00:00
Tom Lane 291a957745 Split the LDFLAGS make variable into two parts: LDFLAGS is now used for
linking both executables and shared libraries, and we add on LDFLAGS_EX when
linking executables or LDFLAGS_SL when linking shared libraries.  This
provides a significantly cleaner way of dealing with link-time switches than
the former behavior.  Also, make sure that the various platform-specific
%.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that
before.  (I did not add these variables for the platforms that invoke $(LD)
directly, however.  It's not clear if we can do that safely, since for the
most part we assume these variables use CC command-line syntax.)

Per gripe from Aaron Swenson and subsequent investigation.
2010-07-05 18:54:38 +00:00
Peter Eisentraut 234c7ce9f2 Derived files that are shipped in the distribution used to be built in the
source directory even for out-of-tree builds.  They are now alsl built in
the build tree.  This should be more convenient for certain developers'
workflows, and shouldn't really break anything else.
2009-08-28 20:26:19 +00:00
Tom Lane 3d167209a7 Make the .DEF file generation rules safe against tabs in exports.txt.
Per bug #5016, although I think the MSVC build scripts may need a similar fix.
2009-08-27 17:55:53 +00:00
Peter Eisentraut 9d182ef002 Update of install-sh, mkinstalldirs, and associated configury
Update install-sh to that from Autoconf 2.63, plus our Darwin-specific
changes (which I simplified a bit).  install-sh is now able to install
multiple files in one run, so we could simplify our makefiles sometime.

install-sh also now has a -d option to create directories, so we don't need
mkinstalldirs anymore.

Use AC_PROG_MKDIR_P in configure.in, so we can use mkdir -p when available
instead of install-sh -d.  For consistency with the rest of the world,
the corresponding make variable has been renamed from $(mkinstalldirs) to
$(MKDIR_P).
2009-08-26 22:24:44 +00:00
Peter Eisentraut 26af72b46b Allow out-of-tree builds on mingw and cygwin
Author: Richard Evans <richard.evans@blueallegro.net>
2009-01-05 09:27:20 +00:00
Peter Eisentraut 218b4e8dd8 Append major version number and for libraries soname major version number
to the gettext domain name, to simplify parallel installations.

Also, rename set_text_domain() to pg_bindtextdomain(), because that is what
it does.
2008-12-11 07:34:09 +00:00
Peter Eisentraut 0884acbcab Move FAQ_AIX information to installation instructions.
The information on why the shared libraries are built the way they are
was not relevant to end users and has been made a mailing list archive
link in Makefile.shlib.
2008-11-24 11:59:37 +00:00
Peter Eisentraut 86ec73b909 Synchronize the shared object build rules in Makefile.port with Makefile.shlib
somewhat by adding CFLAGS where the compiler is used and Makefile.shlib
already used CFLAGS.
2008-09-01 08:50:10 +00:00
Peter Eisentraut db5f60cb18 On cygwin and win32, don't override the shlib name when building a module.
Should fix regression test failures on those platforms.
2008-04-08 09:50:29 +00:00