libxml2 on AIX 5.3, ss_family vs. __ss_family

When trying to build libxml2 2.6.26 on AIX 5.3, I get the
following
error:

nanoftp.c: In function `xmlNanoFTPGetConnection':
nanoftp.c:1382: error: structure has no member named
`__ss_family'
nanoftp.c:1401: error: structure has no member named
`__ss_family'
nanoftp.c:1432: error: structure has no member named
`__ss_family'
nanoftp.c:1469: error: structure has no member named
`__ss_family'
nanoftp.c:1488: error: structure has no member named
`__ss_family'

Note that this is the exact opposite to
http
://bugzilla.gnome.org/show_bug.cgi?id=150836

I think I have seen some changes to configure.in to check
this, so the
#ifdef _AIX stuff in nanoftp.c may be unnecessary (and, in
this case,
wrong).


-- 
%SYSTEM-F-ANARCHISM, The operating system has been
overthrown
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

On Mon, Sep 25, 2006 at 05:15:07PM +0200, Hans Rosenfeld
wrote:
> When trying to build libxml2 2.6.26 on AIX 5.3, I get
the following
> error:
> 
> nanoftp.c: In function `xmlNanoFTPGetConnection':
> nanoftp.c:1382: error: structure has no member named
`__ss_family'
> nanoftp.c:1401: error: structure has no member named
`__ss_family'
> nanoftp.c:1432: error: structure has no member named
`__ss_family'
> nanoftp.c:1469: error: structure has no member named
`__ss_family'
> nanoftp.c:1488: error: structure has no member named
`__ss_family'
> 
> Note that this is the exact opposite to
> http
://bugzilla.gnome.org/show_bug.cgi?id=150836

  Right, this thing has been annoying us like forever. I
dunno why,
probably different compilers, different options on AIX
behaving differently,
probably AIX trying to emulate way too many Unices variants,

> I think I have seen some changes to configure.in to
check this, so the
> #ifdef _AIX stuff in nanoftp.c may be unnecessary (and,
in this case,
> wrong).

  And if we change it, how can we garantee it won't fail
again for the
next user on AIX ??? Someone from IBM should jump in and
look at the issue
once and for all, there is no way we can continue the
flip-flop'ing
of the way this data structure is named. They must know how
to make
it portable, if IBM is willing to certify a patch at this
point I will
take it, but if it's yet another iteration which will fail
for the next
user, I'm not thrilled to try to 'fix' it.
  Unless someone have a battery of different AIXes version
and willing to
test with at least gcc and xlc I'm not sure we should try to
patch it again,
but of course users may disagree, and I would apply a patch
if I get minimal
feedback 

Daniel

-- 
Red Hat Virtualization group http://redhat.com/v
irtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillardredhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ |
Rpmfind RPM search engine  http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

Daniel Veillard wrote:

>   And if we change it, how can we garantee it won't
fail again for the
> next user on AIX ??? Someone from IBM should jump in
and look at the issue
> once and for all, there is no way we can continue the
flip-flop'ing
> of the way this data structure is named. They must know
how to make

Sound like an obvious candidate for autoconf.
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

On Thu, Sep 28, 2006 at 06:41:04PM +0200, Bjorn Reese wrote:
> Daniel Veillard wrote:
> 
> >   And if we change it, how can we garantee it
won't fail again for the
> > next user on AIX ??? Someone from IBM should jump
in and look at the issue
> > once and for all, there is no way we can continue
the flip-flop'ing
> > of the way this data structure is named. They must
know how to make
> 
> Sound like an obvious candidate for autoconf.

  Well you can try a patch that way  , there is
apparently already some
struct sockaddr::ss_family checking in configure, maybe it's
just the .c
which need fixing as the reporter hinted, in any case it's
black magic 

Daniel

-- 
Red Hat Virtualization group http://redhat.com/v
irtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillardredhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ |
Rpmfind RPM search engine  http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml