Thread: 7.1.3 compilation failure (libpq or aync?)
Hello everyone,
I'll lay it all out right from the beginning. I'm very green when it
comes to troubleshooting compilation/library problems. I know just
enough to be break things, and do it really well. =)
I'm trying to compile PostGreSQL 7.1.3 on my slackware (4.0?) box. I
currently have pg 7.0 installed and running. I can successfully
configure and re-compile 7.0, however I'm having trouble compiling
7.1.3 for the first time.
I did the 'configure', which seems to have run properly. I received no
obvious negative messages or errors. I then run a 'make' when runs for
awhile and ends with the following fatal error message:
make[3]: Entering directory `/ext2/src/postgresql-7.1.3/src/backend/commands'
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o async.o async.c
In file included from /usr/include/linux/byteorder/little_endian.h:11,
from /usr/include/asm/byteorder.h:45,
from /usr/include/linux/in.h:177,
from /usr/include/netinet/in.h:79,
from async.c:79:
/usr/include/linux/byteorder/swab.h:100: warning: no previous prototype for `__fswab16'
/usr/include/linux/byteorder/swab.h:104: warning: no previous prototype for `__swab16p'
/usr/include/linux/byteorder/swab.h:108: warning: no previous prototype for `__swab16s'
/usr/include/linux/byteorder/swab.h:113: warning: no previous prototype for `__fswab32'
/usr/include/linux/byteorder/swab.h:117: warning: no previous prototype for `__swab32p'
/usr/include/linux/byteorder/swab.h:121: warning: no previous prototype for `__swab32s'
/usr/include/linux/byteorder/swab.h:127: warning: no previous prototype for `__fswab64'
/usr/include/linux/byteorder/swab.h:137: warning: no previous prototype for `__swab64p'
/usr/include/linux/byteorder/swab.h:141: warning: no previous prototype for `__swab64s'
In file included from ../../../src/include/libpq/libpq-be.h:21,
from ../../../src/include/libpq/libpq.h:21,
from async.c:87:
../../../src/include/libpq/pqcomm.h:33: redefinition of `struct sockaddr_un'
make[3]: *** [async.o] Error 1
make[3]: Leaving directory `/ext2/src/postgresql-7.1.3/src/backend/commands'
make[2]: *** [commands-recursive] Error 2
make[2]: Leaving directory `/ext2/src/postgresql-7.1.3/src/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/ext2/src/postgresql-7.1.3/src'
make: *** [all] Error 2
I tried searching the archives for anyone else discussing async or
libpq problems, but didn't seem to locate any references.
Before I post all kinds of configure/make output and system
configuration (which would be pages and pages) I'm wondering if anyone
has any initial guesses to what the problem might be and how to
resolve it or if more information is required from me, what
would that be?
I appreciate everyone's time, effort, and patience.
Thank you...
--James
James Olsen <jamesml@planetolsen.com> writes:
> I'm trying to compile PostGreSQL 7.1.3 on my slackware (4.0?) box.
> ../../../src/include/libpq/pqcomm.h:33: redefinition of `struct sockaddr_un'
This would seem to be an autoconfiguration failure. If you look at that
include file you'll see that it only tries to define struct sockaddr_un
if HAVE_STRUCT_SOCKADDR_UN is not defined --- which indicates that
configure failed to find any definition of struct sockaddr_un in the
system header files. But evidently there is one; so why didn't
configure find it? Perhaps your system keeps it in an odd place.
Please see if you can figure out why configure missed this.
regards, tom lane
Hello Tom,
TL> James Olsen <jamesml@planetolsen.com> writes:
>> I'm trying to compile PostGreSQL 7.1.3 on my slackware (4.0?) box.
>> ../../../src/include/libpq/pqcomm.h:33: redefinition of `struct sockaddr_un'
TL> This would seem to be an autoconfiguration failure. If you look at that
TL> include file you'll see that it only tries to define struct sockaddr_un
TL> if HAVE_STRUCT_SOCKADDR_UN is not defined --- which indicates that
TL> configure failed to find any definition of struct sockaddr_un in the
TL> system header files.
Thank you for your response. I did a quick cheat and added
'#define HAVE_STRUCT_SOCKADDR_UN 1' to src/config.h and I was able to
successfully build the software.
Thank you!
In regard to troubleshooting "configure":
TL> But evidently there is one; so why didn't
TL> configure find it? Perhaps your system keeps it in an odd place.
TL> Please see if you can figure out why configure missed this.
Unfortunately, this is a bit above my current abilities to
troubleshoot.
It looks like this is the mini-program used to test for sockaddr_un..
#include "confdefs.h"
#include <sys/types.h>
#ifdef HAVE_SYS_UN_H
#include <sys/un.h>
#endif
int main() {
struct sockaddr_un un;
; return 0; }
If I keep the "sys/un.h" include, I get:
In file included from /usr/include/sys/un.h:1,
from test.c:3:
/usr/include/linux/un.h:7: parse error before `sa_family_t'
/usr/include/linux/un.h:7: warning: no semicolon at end of struct or union
/usr/include/linux/un.h:9: parse error before `}'
test.c: In function `main':
test.c:6: storage size of `un' isn't known
If I remove the "sys/un.h" include, I get:
test.c: In function 'main':
test.c:6 storage size of 'un' isn't known
I did some digging, and I think I traced down which un.h is being
used. It's contents are:
=================
ifndef _LINUX_UN_H
#define _LINUX_UN_H
#define UNIX_PATH_MAX 108
struct sockaddr_un {
sa_family_t sun_family; /* AF_UNIX */
char sun_path[UNIX_PATH_MAX]; /* pathname */
};
#endif /* _LINUX_UN_H */
=================
I have no idea what's valid and what's not, or what it should be.
I might be alone in having this problem, I
don't know how much energy should be devoted to rooting out the cause.
of it since I'm now aware of the necessary work-around.
--James
James Olsen <jamesml@planetolsen.com> writes:
> If I keep the "sys/un.h" include, I get:
> In file included from /usr/include/sys/un.h:1,
> from test.c:3:
> /usr/include/linux/un.h:7: parse error before `sa_family_t'
> /usr/include/linux/un.h:7: warning: no semicolon at end of struct or union
> /usr/include/linux/un.h:9: parse error before `}'
> test.c: In function `main':
> test.c:6: storage size of `un' isn't known
It would appear that on your platform, sys/un.h requires another header
file to be included first (whichever one defines sa_family_t). If you
poke around in /usr/include you should be able to find out which.
If you can derive a working test program please send it along.
regards, tom lane