[boost] serialization 1.31 compilation error.

From: Russell Balest (russell_at_[hidden])
Date: 2004-07-06 14:00:27

      Couldn't find this reported in boost archives, but I'm getting the 
following compilation error:
--------
 /usr/include/netinet/ip.h:49: error: syntax error before `:' token
---------

      My configuration:

boost serialization 1.31
g++-3.3
linux 2.4

      In some cases, I can make this go away by reordering my 
boost/serialization headers.
 From what I can tell,  there is a struct defined in serialization with 
the name 'version':

namespace boost {
namespace serialization {
    struct version ...
}
}

Which is colliding with the following definition in ip.h:
struct iphdr
  {
#if __BYTE_ORDER == __LITTLE_ENDIAN
    unsigned int ihl:4;
    unsigned int version:4;         //   <-==  ERROR REPORTED ON THIS LINE
#elif __BYTE_ORDER == __BIG_ENDIAN
    unsigned int version:4;
    unsigned int ihl:4;
#else
# error "Please fix <bits/endian.h>"
#endif
}

Possibly triggered by the using statement:
using namespace boost::serialization;
on line 53 of iserializer.hh , but that's a guess.

   Heard of anything like this?

   Russ Balest

Robert Ramey wrote:

>Johannes Brunen wrote:
>
>  
>
>>>And if there are a large
>>>number of new things left out by that approach then we should plan 
>>>another release sooner rather than waiting 4 months.
>>>      
>>>
>>However, then you need new volunteers which have to spend the time for the
>>whole procedure again.
>>    
>>
>
>The release procedure is too onerous.  This isn't the problem, it's a
>symptom of a more subtle problem. If the source of this difficulty can be
>found can corrected, then releases can occur more frequently.  My personal
>view is that it's a symptom of a development process that couples otherwise
>independent/orthogonal efforts.  This is due to the fact that we're all
>working against a development tree that has experimental code in it. So
>minor issues ripple across all efforts.
>
>  
>
>>I could think of a review process which accepts a library only after the
>>list of requested changes has been made.
>>    
>>
>
>  
>
>>I would prefere a review process which leads to final 
>>acceptance only after a library is 'CVS' compatible i.e. does not yield to
>>any (known) regressions of the existing pool libraries and is equipted 
>>with a working testing facility.
>>    
>>
>
>The review process qualifies submissions for inclusion into boost.  I don't
>think there are any libraries that have been accepted then suffered changes
>which made them unacceptable.  It's not fair to ask a submitter to require
>that that he totally "finish" the package before submission when it cannot
>be guaranteed that it will be accepted.  The review process isn't the
>problem, its working quite well.  
>
>It's just that there is more effort than first meets the eye between the
>time a library is deemed acceptable and the time it is ready for inclusion
>into boost.  The serialization library including code, headers, tests, html,
>jamfiles, *.bat, and shell scripts is has passed 25,0000 lines. This takes
>time and no changes in the review or release procedure can change that.
>There is the review package which seems to work pretty well.  But I would be
>reluctant to check it in as it doesn't match the review acceptance
>conditions and I'm concerned about trying to maintain a package which I have
>now moved beyond.
>
>Robert Ramey
>
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>  
>