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