Thread: problems with configure
I'm trying to compile the CVS (fresh download) of postgres and I get this running the configure script: checking for tzname... yes checking for union semun... no checking for struct sockaddr_un... yes checking for int timezone... yes checking types of arguments for accept()... configure: error: could not determine argument types My configure options are these: ./configure --prefix=/usr/local/pgsql/ --cache-file=config.cache --enable-locale --enable-uniconv --with-maxbackends=128 --without-tk --with-openssl=/usr/local/ssl/ --enable-syslog and I'm running a Solaris 7 with gcc 2.95.2. Any ideas? -- "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:
> 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
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/
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 flagsthe> > third argument can be a pointer to socklen_t, void, size_t or> > int.> > The argument is question cannot possiblybe of a different width> than int, unless someone is *really* on drugs at Sun. Therefore,> if the third argumentto 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 notbe a> problem, since evidently the true argument type varies with> compiler options, but surely the BSD socket layer doesnot. 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