Re: 7.1.3 compilation failure (libpq or aync?)

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