Re: C99 compliance for src/port/snprintf.c
От | Andrew Dunstan |
---|---|
Тема | Re: C99 compliance for src/port/snprintf.c |
Дата | |
Msg-id | 8dfab595-ce96-0290-e3d4-10392fa96b9e@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: C99 compliance for src/port/snprintf.c (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 08/16/2018 12:05 PM, Andres Freund wrote: > Hi, > > On 2018-08-16 11:41:30 -0400, Tom Lane wrote: >> Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: