f



RE: [ace-users] Re: ACE 5.4.0 won't compile after GCC upgrade (3.3.3 -> 3.4.3)

Hi Tom,

> > > The "resolution" was to upgrade to ACE-5.4.3 or later, which has
> > > code fixes to help with the newer compiler. Not sure how 
> much would
> > > need to change, but you may be able to inspect the differences
in
> > > that part of the code wrt the newer ACE release to backport the
> > > fixes.
> >  Thanks, I've downloaded and am building. Is ACE-5.4.3 the latest
> >  production release ?
> 
> Well, the definition of "production release" for ACE is a bit murky 
> imho.

Production release is one with 2 numbers. E.g., 5.4

> The developers on this list (almost) always recommend using the 
> latest package, which is typically labeled a "beta release". 
> The latest 
> would be 5.4.4. The developers always recommend *not* using the 
> "production release", since the next release labeled "beta" 
> is always a bug-fix-only release.

I believe I qualify as a "developer", but have a different take.
Production releases are tested well, and often better than the BFO
beta. There may be fixes in BFO, but there may be additional bugs also
- it happened at 5.4.1.

For those wishing to adopt a version of ACE and stick with it, you'll
need a version you can get support (fixes and advice) for. For
example, Riverace supports releases (e.g., 5.4) and fix kits that
Riverace releases for those (i.e, 5.4a and 5.4b in the 5.4 series).
This allows project teams to stick with a stable ACE API and feature
set and still get the fixes needed.

> So I usually use the x.x.1 release (the BFO 
> release) but would probably recommend using 5.4.4 on any 
> platform, as do the developers.

This works for many people. There is, however, a risk involved. This
email exchange is an illustration of it - once you pick a beta (even
the BFO), the recommended way to get fixes (other than fixing it
yourself) is to go to the latest beta and hope someone has fixed the
problem you're seeing, and hasn't introduced some other problem. This
is too much risk for many projects to take on.

> >  Also, as an FYI, the header file <sys/machine.h> is a
pre-requisite
> >  for <netinet/tcp.h> on AIX 5.2. The configure.ac file may 
> need to be
> >  updated to reflect this.
> 
> I'm not familiar with the autoconf build style for ACE. 
> Perhaps someone else on-list can address this?

Sure... Why do you say <sys/machine.h> is a prerequisite for
<netinet/tcp.h>? I addressed a problem related to this in the autoconf
support for AIX that'll go in the next beta, but it doesn't involve
machine.h.

Thanks,

-Steve

--
Steve Huston, Riverace Corporation
Adding Service to Open Source Software
ACE book info at http://www.riverace.com/acebooks/



0
Steve
4/12/2005 9:54:56 PM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

2 Replies
6582 Views

Similar Articles

[PageSpeed] 30

>Sure... Why do you say <sys/machine.h> is a prerequisite for
><netinet/tcp.h>? I addressed a problem related to this in the autoconf
>support for AIX that'll go in the next beta, but it doesn't involve
>machine.h.
>
Hi Steve,

that statement is based on the compilation sequence shown below (done on 
an AIX 5.2):

$ cat t2.cpp
#include <sys/machine.h>
#include <netinet/tcp.h> 
int main()
{}
$ g++ t2.cpp
$ cat t1.cpp
#include <netinet/tcp.h>
int main()
{}
$ g++ t1.cpp
In file included from /usr/include/netinet/tcp.h:78,
                 from t1.cpp:1:
/usr/include/netinet/ip.h:119: error: declaration of `int 
ip_firstfour::<anonymous union>::<anonymous struct>::ip_xhl'
/usr/include/netinet/ip.h:114: error: conflicts with previous 
declaration `unsigned int ip_firstfour::<anonymous union>::<anonymous 
struct>::ip_xhl'
/usr/include/netinet/ip.h:120: error: declaration of `int 
ip_firstfour::<anonymous union>::<anonymous struct>::ip_xv'
/usr/include/netinet/ip.h:113: error: conflicts with previous 
declaration `unsigned int ip_firstfour::<anonymous union>::<anonymous 
struct>::ip_xv'
/usr/include/netinet/ip.h:121: error: declaration of `int 
ip_firstfour::<anonymous union>::<anonymous struct>::ip_xtos'
/usr/include/netinet/ip.h:115: error: conflicts with previous 
declaration `unsigned int ip_firstfour::<anonymous union>::<anonymous 
struct>::ip_xtos'
/usr/include/netinet/ip.h:122: error: declaration of `int 
ip_firstfour::<anonymous union>::<anonymous struct>::ip_xlen'
/usr/include/netinet/ip.h:116: error: conflicts with previous 
declaration `unsigned int ip_firstfour::<anonymous union>::<anonymous 
struct>::ip_xlen'
$
I experienced the same error when trying to build ACE after running 
configure, and I changed an ACE header file (can't remember which one) 
to include machine.h, and then it compiled.

Thanks,
Colm.

0
Colm
4/13/2005 5:11:57 PM
Colm McHugh <cmchugh@callixa.com> writes:
>>Sure... Why do you say <sys/machine.h> is a prerequisite for
>><netinet/tcp.h>? I addressed a problem related to this in the autoconf
>>support for AIX that'll go in the next beta, but it doesn't involve
>>machine.h.
>>
> Hi Steve,
>
> that statement is based on the compilation sequence shown below (done
> on an AIX 5.2):

I wonder whether we should use something other than <sys/machine.h>
--- maybe <sys/types.h>, <sys/socket.h>, or <netinet/in.h>.  Something
that is more likely to be present on other systems, but defines what's
needed or implicitly #includes <sys/machine.h> on AIX.

A little googling for AIX and netinet/tcp.h shows a lot of autoconf-
based packages complaining about AIX's lack of a idempotent netinet/
tcp.h header.  One in particular is the neon HTTP/WebDAV library,
which has fixed this by including <netinet/in.h> before including
<netinet/tcp.h> in the autoconf test.

    --jtc

-- 
J.T. Conklin

0
jtc
4/13/2005 6:29:37 PM
Reply: