Re: problems with configure - Mailing list pgsql-hackers

From pete.forman@westgeo.com
Subject Re: problems with configure
Date
Msg-id 14858.49805.927548.900018@kryten.bedford.waii.com
Whole thread Raw
In response to Re: problems with configure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: problems with configure
List pgsql-hackers
Tom Lane writes:> If socklen_t exists, it's presumably the right thing to use, so if> we just hardwire "void ->
socklen_t",I think it'd be OK.  If we're> wrong, we'll hear about it...
 

Ah, if only life were that simple ;-/

Depending on the version of Solaris and the compiler flags the third
argument can be a pointer to socklen_t, void, size_t or int.

For Solaris 7 & 8 the impression I get is that accept() is an XPG4v2
thing and so the compile flags should include one of the following
sets of flags.  The first specifies XPG4v2 (UNIX95), the second XPG5
(UNIX98).  Using either will make the third argument socklen_t*.
  -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED
or  -D_XOPEN_SOURCE=500


Solaris 2.6 only groks the first of those.  Setting the flags for
XPG4v2 will use size_t* for arg3, otherwise it will be int*.  The
underlying types are the same width, size_t is unsigned.  I'd expect
that the program would work with either, give or take warnings about
the signedness.

The only choice of arg3 on Solaris 2.5 is int*.


My bottom line is that flags for XPG4v2 should be set on Solaris.
I've successfully run configure from the current CVS sources on
Solaris 7 with the following workaround.  I presume that there is a
better place to apply the change.
   CPPFLAGS="-D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED" configure


-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
Western Geophysical           -./\.-  by myself and does not represent
pete.forman@westgeo.com         -./\.-  the opinion of Baker Hughes or
http://www.crosswinds.net/~petef  -./\.-  its divisions.
***==  My old email address gsez020@kryten.bedford.waii.com will ==***
***==  not be operational from Fri 10 to Tue 14 Nov 2000.        ==***


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: AW: Unhappy thoughts about pg_dump and objects inherite d from template1
Next
From: Tom Lane
Date:
Subject: Re: AW: Unhappy thoughts about pg_dump and objects inherited from template1