problems with configure

Martin A. Marques writes:

checking types of arguments for accept()... configure: error: could not determine argument types

According to the documentation for Solaris 7 it should be 'accept(int,
struct sockaddr *, socklen_t *)', which is the same on my system, so the
problem is elsewhere. One possibility is that the earlier tests for
sys/types.h or sys/socket.h failed. Could you check what the file
config.log says?

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

I'm trying to compile the CVS (fresh download) of postgres and I get this
running the configure script:

checking types of arguments for accept()... configure: error: could not
determine argument types

Hm, how do your system's include files declare accept()?

It would help to see the part of the config.log file that shows the
errors configure gets while trying to find workable input types for
accept().

regards, tom lane

On Vie 03 Nov 2000 22:16, Tom Lane wrote:

Hm, how do your system's include files declare accept()?

It would help to see the part of the config.log file that shows the
errors configure gets while trying to find workable input types for
accept().

The config.log file starts given fails at this point:

configure:5383: checking for struct sockaddr_un
configure:5398: gcc -c -g conftest.c 1>&5
configure:5422: checking for int timezone
configure:5434: gcc -o conftest -g conftest.c -lz -lgen -lnsl -lsocket
-ldl -lm -lreadline -ltermcap -lcurses 1>&5
configure:5454: checking types of arguments for accept()
configure:5481: gcc -c -g conftest.c 1>&5
configure:5475: conflicting types for `accept'
/usr/include/sys/socket.h:384: previous declaration of `accept'
configure: failed program was:
#line 5468 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#endif
extern accept (int, struct sockaddr *, int *);
int main() {

; return 0; }

I see there that the extern accept function is different from the one that
Peter Eisentraut wrote in his mail. Could there be somthing wrong in the cvs
code, or in one of the Solaris headers?

Saludos... :-)

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

On Vie 03 Nov 2000 22:16, Tom Lane wrote:

Hm, how do your system's include files declare accept()?

The config.log file starts given fails at this point:
configure:5475: conflicting types for `accept'
/usr/include/sys/socket.h:384: previous declaration of `accept'

So how does /usr/include/sys/socket.h declare accept() ?

regards, tom lane

On S�b 04 Nov 2000 18:54, Tom Lane wrote:

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

On Vie 03 Nov 2000 22:16, Tom Lane wrote:

Hm, how do your system's include files declare accept()?

The config.log file starts given fails at this point:
configure:5475: conflicting types for `accept'
/usr/include/sys/socket.h:384: previous declaration of `accept'

So how does /usr/include/sys/socket.h declare accept() ?

Well, my socket.h declares accept this way:

extern int accept(int, struct sockaddr *, Psocklen_t);

It's the same line I have on a Solaris 8 Sparc, in which I have a
PostgreSQL-7.0.2 compiled (without a problem) and running.

Saludos... ;-)

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

On Vie 03 Nov 2000 20:37, Peter Eisentraut wrote:

Martin A. Marques writes:

checking types of arguments for accept()... configure: error: could not
determine argument types

According to the documentation for Solaris 7 it should be 'accept(int,
struct sockaddr *, socklen_t *)', which is the same on my system, so the

Well, mine looks like:

extern int accept(int, struct sockaddr *, Psocklen_t);

problem is elsewhere. One possibility is that the earlier tests for
sys/types.h or sys/socket.h failed. Could you check what the file
config.log says?

Everything looks good. No problems with those checks.

I checked the configure on the lines that give the error and I don't
understand what It's trying to do. It has various variables with I don' t
know where they are defined. Can somebody give me a clue?
This is what I have in the configure:

#line 5479 "configure"
#include "confdefs.h"
#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#endif
extern accept ($ac_cv_func_accept_arg1, $ac_cv_func_accept_arg2,
$ac_cv_func_accept_arg3 *);
int main() {

; return 0; }

Saludos... :-)

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart���n Marqu���s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

Well, mine looks like:
extern int accept(int, struct sockaddr *, Psocklen_t);

This is what I have in the configure:
extern accept ($ac_cv_func_accept_arg1, $ac_cv_func_accept_arg2,
$ac_cv_func_accept_arg3 *);

Hmm ... is it possible that his compiler distinguishes between
"extern int foo(...)" and "extern foo(...)" ? Why don't we
have the return type there, anyway?

regards, tom lane

On Lun 06 Nov 2000 12:06, Tom Lane wrote:

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

Well, mine looks like:
extern int accept(int, struct sockaddr *, Psocklen_t);

This is what I have in the configure:
extern accept ($ac_cv_func_accept_arg1, $ac_cv_func_accept_arg2,
$ac_cv_func_accept_arg3 *);

Hmm ... is it possible that his compiler distinguishes between
"extern int foo(...)" and "extern foo(...)" ? Why don't we
have the return type there, anyway?

If it's of any help, I'm on Solaris 7, SPARC, gcc-2.95.2, latest Postgres CVS.
Another question would be, why didn't I have problems of this type when I
compiled PostgreSQL 7.0.2 on Solaris 8, with the same version of gcc?

Thanks for the patience.

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

Hmm ... is it possible that his compiler distinguishes between
"extern int foo(...)" and "extern foo(...)" ? Why don't we
have the return type there, anyway?

If it's of any help, I'm on Solaris 7, SPARC, gcc-2.95.2, latest
Postgres CVS. Another question would be, why didn't I have problems
of this type when I compiled PostgreSQL 7.0.2 on Solaris 8, with the
same version of gcc?

Different header files, likely. I'm starting to wonder if Solaris 7
has some header-file dependency for <sys/socket.h> beyond the one that
the test is allowing for (<sys/types.h>).

BTW, does 'Psocklen_t' equate to just 'socklen_t *', or is there
something strange hidden there?

regards, tom lane

On Lun 06 Nov 2000 13:28, Tom Lane wrote:

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

Hmm ... is it possible that his compiler distinguishes between
"extern int foo(...)" and "extern foo(...)" ? Why don't we
have the return type there, anyway?

If it's of any help, I'm on Solaris 7, SPARC, gcc-2.95.2, latest
Postgres CVS. Another question would be, why didn't I have problems
of this type when I compiled PostgreSQL 7.0.2 on Solaris 8, with the
same version of gcc?

Different header files, likely. I'm starting to wonder if Solaris 7
has some header-file dependency for <sys/socket.h> beyond the one that
the test is allowing for (<sys/types.h>).

Is there any kind of info you would need that I could provide? If you want I
can send the config.log, output of the configure execution, etc. Even the
socket.h and the types.h.
BTW, I didn't find diffs between Solaris 7 .h files and Solaris 8 headers.

BTW, does 'Psocklen_t' equate to just 'socklen_t *', or is there
something strange hidden there?

I don' t have the slightest idea.

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

Martin A. Marques writes:

Is there any kind of info you would need that I could provide? If you want I
can send the config.log, output of the configure execution, etc. Even the
socket.h and the types.h.
BTW, I didn't find diffs between Solaris 7 .h files and Solaris 8 headers.

Try one of the attached patches, first patch1, then patch2, preferrably
each one separately.

(To apply the patch, save the file in the same directory as 'configure'
and run 'patch -p0 < patchx'. Then remove config.cache and rerun
configure.)

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

On Lun 06 Nov 2000 18:25, Peter Eisentraut wrote:

Martin A. Marques writes:
Is there any kind of info you would need that I could provide? If you
want I can send the config.log, output of the configure execution, etc.
Even the socket.h and the types.h.
BTW, I didn't find diffs between Solaris 7 .h files and Solaris 8
headers.

Try one of the attached patches, first patch1, then patch2, preferrably
each one separately.

Didn't work. :-(
This was the output:

martin@ultra208 ~/basura/post-final $ patch -p0 < patch1 Looks like a
context diff to me... Hunk #1 failed at line 5483. 1 out of 1 hunks failed:
saving rejects to configure.rej done

configure.rej contains this:

martin@ultra208 ~/basura/post-final $ less configure.rej
***************
*** 5483,5489 ****
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#endif
! extern accept ($ac_cv_func_accept_arg1, $ac_cv_func_accept_arg2,
$ac_cv_func_accept_arg3 *);
int main() {

  ; return 0; }
--- 5483,5489 ----
  #ifdef HAVE_SYS_SOCKET_H
  #include <sys/socket.h>
  #endif
! extern int accept ($ac_cv_func_accept_arg1, $ac_cv_func_accept_arg2, 
$ac_cv_func_accept_arg3 *);
  int main() {

; return 0; }

Tried to apply what the patch said by hand, ran the configure, but I get the
same error.

I think today afternoon I will try some new things to see where the problem
can be.

Saludos... ;-)

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

Is there any kind of info you would need that I could provide?

If you could put
#include <sys/types.h>
#include <sys/socket.h>
into a file temp.c, and then send the output of "gcc -E temp.c",
it might shed some light.

There it goes!!

Well, that tells the tale all right: the critical lines are

typedef uint32_t socklen_t;

typedef void *Psocklen_t;

extern int accept(int, struct sockaddr *, Psocklen_t);

What brainless idiot decided it would be a good idea to declare
accept's last argument as void*, do you suppose? (At least you
report that Solaris 8 no longer has this folly, so they did get
a clue eventually.)

Not sure what to do about this. It will clearly not do to define
ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for
Solaris 7: if we detect that accept() is declared with "void *",
assume that socklen_t is the thing to use. Peter, any thoughts?

regards, tom lane

On Mi� 08 Nov 2000 18:01, Tom Lane wrote:

Well, that tells the tale all right: the critical lines are

typedef uint32_t socklen_t;

typedef void *Psocklen_t;

extern int accept(int, struct sockaddr *, Psocklen_t);

What brainless idiot decided it would be a good idea to declare
accept's last argument as void*, do you suppose? (At least you
report that Solaris 8 no longer has this folly, so they did get
a clue eventually.)

Not sure what to do about this. It will clearly not do to define
ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for
Solaris 7: if we detect that accept() is declared with "void *",
assume that socklen_t is the thing to use. Peter, any thoughts?

No. Forgot to tell my latest experience.

1) postgres 7.0.2 compiles great on Solaris 7 and Solaris 8.
2) postgres cvs (latest download) doesn't compile (same error on both) on
Solaris 7 nor Solaris 8.

So it isn't a Solaris 7 problem, but a Solaris problem. ;-)
I just wish we could install linux on one of these SPARC to have something
good running. ;-)

Saludos... :-)

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

"Martin A. Marques" <martin@math.unl.edu.ar> writes:

No. Forgot to tell my latest experience.

1) postgres 7.0.2 compiles great on Solaris 7 and Solaris 8.
2) postgres cvs (latest download) doesn't compile (same error on both) on
Solaris 7 nor Solaris 8.

Ah so. 7.0.*'s configure didn't try to determine the exact datatype of
accept()'s arguments, which is why it didn't run into this problem.

So it isn't a Solaris 7 problem, but a Solaris problem. ;-)

I guess we not only need a hack, but a nastygram or three sent off to
the Solaris people. void *? What in heavens name were they thinking?
That essentially means you've got no parameter type checking at all
on calls to accept() --- or any other socket function that takes a
socklen_t. Pass the wrong-size integer, you're out of luck ... silently.
Sheesh.

regards, tom lane

On Mi� 08 Nov 2000 18:17, Tom Lane wrote:

I guess we not only need a hack, but a nastygram or three sent off to
the Solaris people. void *? What in heavens name were they thinking?
That essentially means you've got no parameter type checking at all
on calls to accept() --- or any other socket function that takes a
socklen_t. Pass the wrong-size integer, you're out of luck ... silently.
Sheesh.

I have to say that I'm totally with you on the thoughts about Solaris's
implementation. It's not the first time I have problems compiling. Trying to
compile KDE2-alpha some time ago I had to hack on of the ICE headers which
had some sort of problem trying to determine the size of ... I can't remember
what, so even Open windows has it's bugs, which aren't fixxed in Solaris 8.

To finish, which would be the status all this Solaris + Postgres cvs stuff?

Saludos... :-)

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

Tom Lane writes:

Not sure what to do about this. It will clearly not do to define
ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for
Solaris 7: if we detect that accept() is declared with "void *",
assume that socklen_t is the thing to use. Peter, any thoughts?

Perhaps we could, in case "void *" is discovered, run a similar deal with
bind() or setsockopt(), i.e., some socket function that takes a
non-pointer socklen_t (or whatever), in order to find out the true nature
of what's behind the "void *".

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

Not sure what to do about this. It will clearly not do to define
ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for
Solaris 7: if we detect that accept() is declared with "void *",
assume that socklen_t is the thing to use. Peter, any thoughts?

Perhaps we could, in case "void *" is discovered, run a similar deal with
bind() or setsockopt(), i.e., some socket function that takes a
non-pointer socklen_t (or whatever), in order to find out the true nature
of what's behind the "void *".

Well, maybe. But is it worth the trouble? Hard to believe anyone else
did the same thing.

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...

regards, tom lane

On Mi� 08 Nov 2000 19:34, Tom Lane wrote:

Well, maybe. But is it worth the trouble? Hard to believe anyone else
did the same thing.

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...

Well, I would like to know how this is going to evolve. I will try to
download an update with cvsup in a few hours.
Hope theres something new. Else, please tell me what would be the best
solution (even for the moment).

Thanks

--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-----------------------------------------------------------------
Mart�n Marqu�s email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------

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. ==***

pete.forman@westgeo.com writes:

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.

I think what I'm going to do is this: The argument is question cannot
possibly be of a different width than int, unless someone is *really* on
drugs at Sun. Therefore, if the third argument to accept() is "void *"
then we just take "int". Evidently there will not be a compiler problem
if you pass an "int *" where a "void *" is expected. The fact that int
may be signed differently than the actual argument should not be a
problem, since evidently the true argument type varies with compiler
options, but surely the BSD socket layer does not.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut writes:

pete.forman@westgeo.com writes:

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.

The argument is question cannot possibly be of a different width
than int, unless someone is *really* on drugs at Sun. Therefore,
if the third argument to accept() is "void *" then we just take
"int". Evidently there will not be a compiler problem if you pass
an "int *" where a "void *" is expected. The fact that int may be
signed differently than the actual argument should not be a
problem, since evidently the true argument type varies with
compiler options, but surely the BSD socket layer does not.

Unless there is more than one library that implements accept, or if
accept is mapped as a macro to another function.

Whatever, I'd be happier if "void *" were mapped to "unsigned int*" as
that is what the Solaris 7 library is expecting. But it's no big deal
if you want to go with signed.
--
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. ==***

Peter Eisentraut <peter_e@gmx.net> writes:

pete.forman@westgeo.com writes:

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.

I think what I'm going to do is this: The argument is question cannot
possibly be of a different width than int, unless someone is *really* on
drugs at Sun. Therefore, if the third argument to accept() is "void *"
then we just take "int".

Sounds like a plan to me.

regards, tom lane