[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/42474: Tru64: chat/epic4-2.2 does not compile
The following reply was made to PR pkg/42474; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
Subject: Re: pkg/42474: Tru64: chat/epic4-2.2 does not compile
Date: Sun, 15 Aug 2010 03:30:11 +0000
On Sat, Aug 07, 2010 at 08:45:02AM +0000, RUMI Szabolcs wrote:
> checking to see if your struct sockaddr includes a length field... yes
> #if defined(_SOCKADDR_LEN) || \
> defined(_KERNEL) || \
> defined(_XOPEN_SOURCE_EXTENDED) || \
> unsigned char sa_len; /* total length */
> sa_family_t sa_family; /* address family */
> #else /* BSD4.3 */
> unsigned short sa_family; /* address family */
I thought I remembered something like that...
(I used to use Tru64/Digital Unix a fair amount years back)
The part I don't understand is why one of those symbols is defined
when the configure test runs and then isn't defined when compiling
afterwards. I also don't understand how any of them get defined during
configure, since they don't appear in configure script or anywhere in
the package distribution either.
These two questions probably have the same answer, though. Maybe
there's a header being pulled in during configure that sets one of
them? If you feel inclined, you might look in confdefs.h and see if
there's anything in there that might be related.
> It seems to me that gailib.h (which is included by gailib.c)
> has some workarounds in place for those missing length fields,
> so this may be the reason why it doesn't fail while others do.
Yeah, but those workarounds are based on the HAVE_*_LEN symbols
defined by the configure script; those are also present in the file
that's failing, and they must be getting set, too, because otherwise
it wouldn't be trying to use the _len fields.
> Issuing 'echo "CFLAGS+=-D_SOCKADDR_LEN" >> /usr/pkg/etc/mk.conf'
> does make it compile.
I'm tempted to deal with the problem by adding
to the package makefile and leave it at that...
David A. Holland
Main Index |
Thread Index |