CVS -Tip compile issue -- FreeBSD 4.8

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

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

First thought that comes to mind is that <sys/socket.h> may require
something else to be included first --- maybe <sys/types.h> ?

That did it. It's a little curious that sys/socket.h doesn't mention
that anywhere though.

--
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc

Rod Taylor <rbt@rbt.ca> writes:

First thought that comes to mind is that <sys/socket.h> may require
something else to be included first --- maybe <sys/types.h> ?

That did it. It's a little curious that sys/socket.h doesn't mention
that anywhere though.

I see a couple of places where configure neglects to include sys/types
before sys/socket. Fixing now.

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
  INSERT INTO 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 all values 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 new gdtoa: 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 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.

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

The man page for socket on Linux says you need both, but you can get away
without it.

It's easy enough to test if a platform does the sane thing:

[andrew@Thor andrew]$ echo '#include <sys/socket.h>' > blurfl.c
[andrew@Thor andrew]$ gcc -E -M blurfl.c
blurfl.o: blurfl.c /usr/include/sys/socket.h /usr/include/features.h \
/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
/usr/include/sys/uio.h /usr/include/sys/types.h \
[snip]

Probably the best bet is just include sys/types.h just before any place
sys/socket.h is included, no? Should be harmless enough.

cheers

andrew

Tom Lane wrote:

Rod Taylor writes:

First thought that comes to mind is that <sys/socket.h> may require
something else to be included first --- maybe <sys/types.h> ?

That did it. It's a little curious that sys/socket.h doesn't mention
that anywhere though.

Because it shouldn't be so. Can you look in config.log what the real
reason of the failure was? Maybe it's a bug in FreeBSD.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Rod Taylor writes:

First thought that comes to mind is that <sys/socket.h> may require
something else to be included first --- maybe <sys/types.h> ?

That did it. It's a little curious that sys/socket.h doesn't mention
that anywhere though.

Because it shouldn't be so. Can you look in config.log what the real
reason of the failure was? Maybe it's a bug in FreeBSD.

It's been true for years that <sys/socket.h> requires <sys/types.h> on
some platforms. How do you think I knew what to recommend? There's
no point in arguing about it, it's just a fact.

regards, tom lane

Tom Lane writes:

It's been true for years that <sys/socket.h> requires <sys/types.h> on
some platforms. How do you think I knew what to recommend? There's
no point in arguing about it, it's just a fact.

Sure, but it still may be a bug in FreeBSD if they don't document it and
if they pretend to follow standards, which they do.

--
Peter Eisentraut peter_e@gmx.net