On 08/16/2018 12:05 PM, Andres Freund wrote:
Hi,
On 2018-08-16 11:41:30 -0400, Tom Lane wrote:
Andres Freund <and...@anarazel.de> writes:
But enabling C99 support triggered a somewhat weird failure on
protosciurus (also solaris, but gcc)
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=protosciurus&dt=2018-08-16%2013%3A37%3A46
It detects C99 support successfully via -std=gnu99 but then fails
somewhere during build with:
../../../../src/include/utils/float.h:71: error: `__builtin_infinity'
undeclared (first use in this function)
While I'd personally have no problem kicking gcc 3.4 to the curb, I'm
still confused what causes this error mode. Kinda looks like
out-of-sync headers with gcc or something.
Yeah, this is *absolutely* unsurprising for a non-native gcc installation
on an old platform. It only works to the extent that the platform's
library headers are up to snuff. The gcc installation process actually
knows enough to do a certain amount of editing of the platform's headers,
and install "fixed" copies of those headers where gcc will find them
before the ones in /usr/include. But it looks like the fixing didn't
account for __builtin_infinity on this platform. Maybe a newer gcc
would get it right.
Sure, but that still requires the headers to behave differently between
C89 and C99 mode, as this worked before. But it turns out there's two
different math.h implementation headers, depending on c99 being enabled
(math_c99.h being the troublesome). If I understand correctly the
problem is more that the system library headers are *newer* (and assume
a sun studio emulating/copying quite a bit of gcc) than the gcc that's
being used, and therefore gcc fails.
Gcc 3.4.3 has been released November 4, 2004, whereas solaris 10 is from
January 31, 2005. The sun studio used for castoroides running on, I
assume, the same hardware, is quite a bit newer in turn.
I just launched gaur/pademelon builds for you, though I'm quite certain
they'll both report "unsupported".
Yea, that seems fairly likely.
If we go through with this, my plan would be to retire pademelon
(vendor's compiler) and see if I can install gcc 4.something to
replace the 2.95.3 version that gaur is using.
K.
The -ansi option that dromedary is using is certainly losable, too
(I'd probably replace it with either --std=c99 or --std=gnu99,
whichever autoconf *doesn't* pick by default, just to be contrary).
Makes sense.
Andrew is going to need to give us a policy decision on whether to
keep using the existing animal names or take out new ones for these
rather-significantly-modified configurations.
CCed.
The usual policy is that animal names need to change if the OS or
compiler names change, but not if just the versions of those change.
There is a script in the suite to update those settings, and the admins
can also help if necessary.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
