Thread: CVS -Tip compile issue -- FreeBSD 4.8
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -g -Wall -Wmissing-prototypes -Wmissin g-declarations -I../../../../src/include -c -o printtup.o printtup.c -MMD In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:41: warning: `_SS_ALIGNSIZE' redefined /usr/include/sys/socket.h:182: warning: this is the location of the previous definition ../../../../src/include/libpq/pqcomm.h:46: warning: `_SS_PAD1SIZE' redefined /usr/include/sys/socket.h:183: warning: this is the location of the previous definition ../../../../src/include/libpq/pqcomm.h:48: warning: `_SS_PAD2SIZE' redefined /usr/include/sys/socket.h:185: warning: this is the location of the previous definition In file included from ../../../../src/include/libpq/libpq-be.h:22, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: ../../../../src/include/libpq/pqcomm.h:50: redefinition of `struct sockaddr_storage' gmake[4]: *** [printtup.o] Error 1 -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
It would seem the configure test isn't picking up on the structure. checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes <--snip--> checking for struct sockaddr_storage... no FreeBSD sys/socket.h is attached. Failing configure test below from config/c-library.m4 (line wrapped) # PGAC_STRUCT_SOCKADDR_STORAGE # ---------------------------- # If `struct sockaddr_storage' exists, define HAVE_STRUCT_SOCKADDR_STORAGE. If # it is missing then one could define it. AC_DEFUN([PGAC_STRUCT_SOCKADDR_STORAGE], [AC_CHECK_TYPES([struct sockaddr_storage], [], [], [#ifdef HAVE_SYS_SOCKET_H #include <sys/socket.h> #endif ])])# PGAC_STRUCT_SOCKADDR_STORAGE On Thu, 2003-06-12 at 09:30, Rod Taylor wrote: > gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -g -Wall > -Wmissing-prototypes -Wmissin g-declarations -I../../../../src/include > -c -o printtup.o printtup.c -MMD > In file included from ../../../../src/include/libpq/libpq-be.h:22, > from ../../../../src/include/libpq/libpq.h:21, > from printtup.c:20: > ../../../../src/include/libpq/pqcomm.h:41: warning: `_SS_ALIGNSIZE' > redefined > /usr/include/sys/socket.h:182: warning: this is the location of the > previous definition > ../../../../src/include/libpq/pqcomm.h:46: warning: `_SS_PAD1SIZE' > redefined > /usr/include/sys/socket.h:183: warning: this is the location of the > previous definition > ../../../../src/include/libpq/pqcomm.h:48: warning: `_SS_PAD2SIZE' > redefined > /usr/include/sys/socket.h:185: warning: this is the location of the > previous definition > In file included from ../../../../src/include/libpq/libpq-be.h:22, > from ../../../../src/include/libpq/libpq.h:21, > from printtup.c:20: > ../../../../src/include/libpq/pqcomm.h:50: redefinition of `struct > sockaddr_storage' > gmake[4]: *** [printtup.o] Error 1 -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Attachment
Rod Taylor <rbt@rbt.ca> writes:
> It would seem the configure test isn't picking up on the structure.
It works here (where "works" is defined as "finds the struct on Linux
and doesn't find it on HPUX" --- both correct according to a search
of /usr/include). You'll need to dig into why it fails on BSD.
First thought that comes to mind is that <sys/socket.h> may require
something else to be included first --- maybe <sys/types.h> ?
regards, tom lane
> It would seem the configure test isn't picking up on the structure. > > checking sys/socket.h usability... yes > checking sys/socket.h presence... yes > checking for sys/socket.h... yes > <--snip--> > checking for struct sockaddr_storage... no Hrm.... on 5.1-CURRENT (~3 days old) it works: checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes [snip] checking for union semun... yes checking for struct sockaddr_un... yes checking for struct sockaddr_storage... yes Your include dir may be hosted... do any recent upgrades and what version of FreeBSD? -sc -- Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
>> checking for struct sockaddr_storage... no
> Hrm.... on 5.1-CURRENT (~3 days old) it works:
When did you last update from our CVS? I corrected the configure test
a couple hours ago ...
regards, tom lane
> >> checking for struct sockaddr_storage... no > > > Hrm.... on 5.1-CURRENT (~3 days old) it works: > > When did you last update from our CVS? I corrected the configure test > a couple hours ago ... Oh.... err, umm.... 'bout 10minutes ago I Sup'ed and checked. *wanders off to go read -committers* -sc -- Sean Chittenden
> > >> checking for struct sockaddr_storage... no
> >
> > > Hrm.... on 5.1-CURRENT (~3 days old) it works:
> >
> > When did you last update from our CVS? I corrected the configure test
> > a couple hours ago ...
>
> Oh.... err, umm.... 'bout 10minutes ago I Sup'ed and checked.
>
> *wanders off to go read -committers*
I must have caught pgsql at a bad time last time when I was getting 5
failed checks on pgsql in the regression tests.. though I'm still
getting a failure for float8:
*** ./expected/float8-small-is-zero.out Tue Mar 11 13:01:33 2003
--- ./results/float8.out Thu Jun 12 11:34:21 2003
***************
*** 274,280 ****
--- 274,282 ---- INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400'); ERROR: Input '-10e400' is out of range for float8
INSERTINTO FLOAT8_TBL(f1) VALUES ('10e-400');
+ ERROR: Input '10e-400' is out of range for float8 INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
+ ERROR: Input '-10e-400' is out of range for float8 -- maintain external table consistency across platforms -- delete
allvalues and reinsert well-behaved ones DELETE FROM FLOAT8_TBL;
======================================================================
I don't know where that conversation left off, but it'd be nice to get
some kind of conditional regarding that. FreeBSD 4.X has older
floating point routines and 5.X has the latest and greatest version of
gdtoa, which fixes many standardization bits in FreeBSD's floating
point routines.
Tom, you said you needed a shell way of detecting this, does the
following work?
if [ "`uname`" = FreeBSD ]; then if [ "`sysctl -n kern.osreldate`" -ge "500110" ]; then echo "Has
newgdtoa: new float handling" else echo "Older float routines" fi
fi
-sc
--
Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
> Tom, you said you needed a shell way of detecting this, does the
> following work?
No, I need something that will work in the regression test resultmap,
which basically only knows about the platform identifier string
computed by config.guess.
We could changefloat8/i.86-.*-freebsd=float8-small-is-zero
tofloat8/i.86-.*-freebsd4=float8-small-is-zero
which would result in the right behavior on freebsd 4.*, and would
expect 5.* to have standard float behavior.
That would mean that on 5.* you would get diffs if you didn't have the
new float handling. What is the status of the 5.* branch --- are there
stable releases out there that don't have the new float code? If not,
this seems like an acceptable answer.
regards, tom lane
> > Tom, you said you needed a shell way of detecting this, does the > > following work? > > No, I need something that will work in the regression test > resultmap, which basically only knows about the platform identifier > string computed by config.guess. > > We could change > float8/i.86-.*-freebsd=float8-small-is-zero > to > float8/i.86-.*-freebsd4=float8-small-is-zero > which would result in the right behavior on freebsd 4.*, and would > expect 5.* to have standard float behavior. > > That would mean that on 5.* you would get diffs if you didn't have > the new float handling. What is the status of the 5.* branch --- > are there stable releases out there that don't have the new float > code? If not, this seems like an acceptable answer. Agreed. Only 5.0 would fail, but those using 5.0 need to upgrade for various reasons. 5.0 and 5.1 are considered early adopter releases by the release engineering team and 5.2 will be classified as the 1st production grade version of the 5.X branch. Those running 5.0 will likely upgrade to 5.1 quickly so I'd say it's safe to let the regression tests fail on 5.0 given it should have a tiny user base in a month. Making the proposed change above fixes the regression tests on my 5.1... I don't have any 4.X machines I can play with at the moment, Rod would have to test that. -sc -- Sean Chittenden
> > We could change > > float8/i.86-.*-freebsd=float8-small-is-zero > > to > > float8/i.86-.*-freebsd4=float8-small-is-zero This change compiles / regresses fine for me, but I didn't read the whole thread to try to see what to look for. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
> > > We could change > > > float8/i.86-.*-freebsd=float8-small-is-zero > > > to > > > float8/i.86-.*-freebsd4=float8-small-is-zero > > This change compiles / regresses fine for me, but I didn't read the > whole thread to try to see what to look for. FreeBSD 5.1 imported gdtoa which fixed the handling of float overflow and underflow conditions, which PostgreSQL used to work around Now that 5.1 is fixed with respect to float handling, the regression tests were b0rk3d. The above fixes things so that PostgreSQL works in both the 4.X and 5.X cases even though their handling is different. -sc -- Sean Chittenden
Rod Taylor <rbt@rbt.ca> writes:
>> We could change
>> float8/i.86-.*-freebsd=3Dfloat8-small-is-zero
>> to
>> float8/i.86-.*-freebsd4=3Dfloat8-small-is-zero
> This change compiles / regresses fine for me, but I didn't read the
> whole thread to try to see what to look for.
Good enough --- change committed.
Does anyone know if FreeBSD 3.* or before still exist in the wild?
We might have to tweak the pattern to match those too.
regards, tom lane
> >> We could change > >> float8/i.86-.*-freebsd=3Dfloat8-small-is-zero > >> to > >> float8/i.86-.*-freebsd4=3Dfloat8-small-is-zero > > > This change compiles / regresses fine for me, but I didn't read the > > whole thread to try to see what to look for. > > Good enough --- change committed. > > Does anyone know if FreeBSD 3.* or before still exist in the wild? > We might have to tweak the pattern to match those too. Ehh.... it probably does. I get emails once every 2-3 mo from someone running it on a 2.x box and that code's probably 6-8 years old at this point. If you wanted to be super judicious about preserving backward compatibility, you could add freebsd2 and freebsd3 to the list too. -sc -- Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
>> Does anyone know if FreeBSD 3.* or before still exist in the wild?
>> We might have to tweak the pattern to match those too.
> Ehh.... it probably does. I get emails once every 2-3 mo from
> someone running it on a 2.x box and that code's probably 6-8 years old
> at this point. If you wanted to be super judicious about preserving
> backward compatibility, you could add freebsd2 and freebsd3 to the
> list too.
Okay, now it looks like
float8/i.86-.*-freebsd[234]=float8-small-is-zero
regards, tom lane