Re: [xml] ss_family compilation error

["William M. Brack" <wbrack mmm com hk>]

Doug Orleans said:
> I'm trying to compile libxml2 on Tru64, but I get this error message:
>
>   cc: Error: nanoftp.c, line 1382: In this statement, "ss_family" is not a
> member of "(ctxt->ftpAddr)". (needmember)
>       if ((ctxt->ftpAddr).ss_family == AF_INET6) {
>   --------^
>
> I found a few occurrences of this in the list archives, and the
> standard answer is to turn off IPv6 support with configure --disable-ipv6.
> However, I believe this is unnecessary, and the error is simply due to
> a bug in configure.in.
>
> The code in nanoftp.c needs to use the ss_family field of the
> sockaddr_storage struct.  But instead of actually testing whether the
> ss_family field exists, the configure script tests whether the
> __ss_family field exists; if so, it concludes that ss_family does not
> exist, and adds the following definition to config.h:
>
>   #define ss_family __ss_family
>
> However, on Tru64, both fields exist!  Actually, the field is named
> ss_family, but there is also the following definition in
> /usr/include/sys/socket.h:
>
>   #define __ss_family ss_family
>
> Because config.h is included before sys/socket.h, the first definition
> comes before the declaration of the sockaddr_storage struct, so the
> field gets named __ss_family, but then the reference to the field in
> nanoftp.c stays ss_family due to the circular definitions.
>
> I believe the most straightforward way to fix this would be to add a
> test to configure.in to detect whether ss_family exists, and only if
> it does not exist should it try to use __ss_family instead.  I've
> never used autoconf before, though, so I would rather let someone else
> with more experience write up an actual patch.
>
> If I'm missing something, please let me know.
>
> --dougo place org

It looks to me as though your analysis is absolutely correct.  In fact, I have
always wondered why the previously reported problems were occurring on so many
HP systems.

I have enhanced the code in configure.in so that it first checks whether
ss_family is present, and only when it is missing does the check for
__ss_family.  I also added a warning if both are not found.  I checked the
enhanced configure on an HP Tru64 system, and it seems to work ok.  The
changed file is in CVS - please try it and let us know if there are any
further problems.

Thanks for your report, and for the time and effort you spent in chasing this
bug.

Bill