Re: problems with configure

From: pete(dot)forman(at)westgeo(dot)com
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: problems with configure
Date: 2000-11-09 15:28:13
Message-ID: 14858.49805.927548.900018@kryten.bedford.waii.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)forman(at)westgeo(dot)com -./\.- the opinion of Baker Hughes or
http://www.crosswinds.net/~petef -./\.- its divisions.
***== My old email address gsez020(at)kryten(dot)bedford(dot)waii(dot)com will ==***
***== not be operational from Fri 10 to Tue 14 Nov 2000. ==***

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-11-09 15:36:44 Re: AW: Unhappy thoughts about pg_dump and objects inherited from template1
Previous Message Tom Lane 2000-11-09 15:19:53 Re: AW: Unhappy thoughts about pg_dump and objects inherite d from template1