In my project, I recently decided to use boost::thread. My code compiles fine under Linux, but under Windows (either x86 or x64), I get the following warnings with gcc 4.5:
In file included from C:\Boost\include\boost-1_44/boost/thread/shared_mutex.hpp:14:0,
from C:\Boost\include\boost-1_44/boost/thread/detail/thread_group.hpp:9,
from C:\Boost\include\boost-1_44/boost/thread/thread.hpp:24,
from C:\Boost\include\boost-1_44/boost/thread.hpp:13,
from include\systools/upnp_control_point.hpp:50,
from src\upnp_control_point.cpp:45:
C:\Boost\include\boost-1_44/boost/thread/win32/shared_mutex.hpp: In member function 'T boost::shared_mutex::interlocked_
compare_exchange(T*, T, T) [with T = boost::shared_mutex::state_data]':
C:\Boost\include\boost-1_44/boost/thread/win32/shared_mutex.hpp:110:103: instantiated from here
C:\Boost\include\boost-1_44/boost/thread/win32/shared_mutex.hpp:50:99: error: dereferencing type-punned pointer will bre
ak strict-aliasing rules
C:\Boost\include\boost-1_44/boost/thread/win32/shared_mutex.hpp:50:99: error: dereferencing type-punned pointer will bre
ak strict-aliasing rules
C:\Boost\include\boost-1_44/boost/thread/win32/shared_mutex.hpp:51:52: error: dereferencing type-punned pointer will bre
ak strict-aliasing rules
C:\Boost\include\boost-1_44/boost/thread/win32/shared_mutex.hpp:51:52: error: dereferencing type-punned pointer will bre
ak strict-aliasing rules
In file included from C:\Boost\include\boost-1_44/boost/algorithm/string/detail/find_format.hpp:18:0,
from C:\Boost\include\boost-1_44/boost/algorithm/string/find_format.hpp:23,
from C:\Boost\include\boost-1_44/boost/algorithm/string/replace.hpp:22,
from C:\Boost\include\boost-1_44/boost/date_time/date_facet.hpp:17,
from C:\Boost\include\boost-1_44/boost/date_time/gregorian/gregorian_io.hpp:16,
from C:\Boost\include\boost-1_44/boost/date_time/gregorian/gregorian.hpp:31,
from C:\Boost\include\boost-1_44/boost/date_time/posix_time/time_formatters.hpp:12,
from C:\Boost\include\boost-1_44/boost/date_time/posix_time/posix_time.hpp:24,
from include\systools/upnp_device.hpp:51,
from include\systools/upnp_control_point.hpp:48,
from src\upnp_control_point.cpp:45:
C:\Boost\include\boost-1_44/boost/algorithm/string/detail/find_format_store.hpp: At global scope:
C:\Boost\include\boost-1_44/boost/algorithm/string/detail/find_format_store.hpp: In instantiation of 'bool boost::algori
thm::detail::check_find_result(InputT&, FindResultT&) [with InputT = std::basic_string<char>, FindResultT = boost::itera
tor_range<__gnu_cxx::__normal_iterator<char*, std::basic_string<char> > >]':
C:\Boost\include\boost-1_44/boost/algorithm/string/detail/find_format_all.hpp:259:17: instantiated from 'void boost::a
lgorithm::detail::find_format_all_impl(InputT&, FinderT, FormatterT, FindResultT) [with InputT = std::basic_string<char>
, FinderT = boost::algorithm::detail::first_finderF<const char*, boost::algorithm::is_equal>, FormatterT = boost::algori
thm::detail::const_formatF<boost::iterator_range<const char*> >, FindResultT = boost::iterator_range<__gnu_cxx::__normal
_iterator<char*, std::basic_string<char> > >]'
C:\Boost\include\boost-1_44/boost/algorithm/string/find_format.hpp:268:13: instantiated from 'void boost::algorithm::f
ind_format_all(SequenceT&, FinderT, FormatterT) [with SequenceT = std::basic_string<char>, FinderT = boost::algorithm::d
etail::first_finderF<const char*, boost::algorithm::is_equal>, FormatterT = boost::algorithm::detail::const_formatF<boos
t::iterator_range<const char*> >]'
C:\Boost\include\boost-1_44/boost/algorithm/string/replace.hpp:654:13: instantiated from 'void boost::algorithm::repla
ce_all(SequenceT&, const Range1T&, const Range2T&) [with SequenceT = std::basic_string<char>, Range1T = char [15], Range
2T = char [1]]'
C:\Boost\include\boost-1_44/boost/units/detail/utility.hpp:50:51: instantiated from here
C:\Boost\include\boost-1_44/boost/algorithm/string/detail/find_format_store.hpp:74:18: error: unused parameter 'Input'
scons: *** [src\upnp_control_point.o] Error 1
scons: building terminated because of errors.
I just included <boost/thread.hpp> in my own .cpp file, nothing special.
Since I have no control over boost's code, is there a way to suppress those warnings temporarily ? Something like:
#super_killing_macro_that_disable_some_warnings
#include <boost/thread.hpp>
#its_all_good_know_i_want_my_warnings_back
What can I do ?
I just discovered the -isystem option that allow to include a directory as a system directory. No warnings are emited from files within thoses directories so it seems perfect for my task.
Also, this has the neat side effect to make SCons ignore those directories as well in the dependency tree. Since I'm not expecting those libraries to change often, it's fine.
you may have some luck with diagnostic pragma:
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
I am having almost the same warnings on Windows XP SP3 with MinGW installed from mingw-get-inst-20101030 with GCC 4.5.0 and boost 1.45.0 built as indicated here
http://fw-geekycoder.blogspot.com/2010/12/building-boost-using-mingw.html
I am using the BOOST_THREAD_USE_LIB compiler flag and the -lboost_thread-mgw45-mt-1_45 linker flag. The only four warnings I am getting are as follows at the end of this post.
C:\workspace\boost_1_45_0/boost/thread/win32/shared_mutex.hpp:113:103: instantiated from here
C:\workspace\boost_1_45_0/boost/thread/win32/shared_mutex.hpp:53:99: warning: dereferencing type-punned pointer will break strict-aliasing rules
C:\workspace\boost_1_45_0/boost/thread/win32/shared_mutex.hpp:53:99: warning: dereferencing type-punned pointer will break strict-aliasing rules
C:\workspace\boost_1_45_0/boost/thread/win32/shared_mutex.hpp:54:52: warning: dereferencing type-punned pointer will break strict-aliasing rules
C:\workspace\boost_1_45_0/boost/thread/win32/shared_mutex.hpp:54:52: warning: dereferencing type-punned pointer will break strict-aliasing rules
I haven't been able to get the resulting code not to crash yet, so I don't know if these warnings are important or not (by checking to see if threading changes my numerical results).
Related
Earlier today, gcc gave me a warning that I belive to be erroneous and now I am very unsure if it is an actual compiler bug(usually highly unlikely) or a bug in my code(usually highly likely). I managed to reduce it down to the following code:
#include <algorithm>
#include <array>
#include <iostream>
int main()
{
std::array<int,8> test{};
int valid = 0;
for(int i=0;i<8;++i)
{
if(i==0)
test[valid++] = 0;
}
// if(valid<8)
std::sort(test.begin(),test.begin()+valid);
}
Here it is on Compiler explorer
When compiled with optimization level -O2 or higher with gcc 12.1 or trunk, this warning about an out-of-bounds access is emitted:
In file included from /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/algorithm:61,
from <source>:1:
In function 'void std::__final_insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]',
inlined from 'void std::__final_insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1844:5,
inlined from 'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1940:31,
inlined from 'void std::__sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare = __gnu_cxx::__ops::_Iter_less_iter]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1932:5,
inlined from 'void std::sort(_RAIter, _RAIter) [with _RAIter = int*]' at /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:4820:18,
inlined from 'int main()' at <source>:16:15:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/stl_algo.h:1849:32: error: array subscript 16 is outside array bounds of 'std::array<int, 8> [1]' [-Werror=array-bounds]
1849 | std::__insertion_sort(__first, __first + int(_S_threshold), __comp);
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>: In function 'int main()':
<source>:7:27: note: at offset 64 into object 'test' of size 32
7 | std::array<int,8> test{};
I believe that to be mistaken. According to my limited understanding, valid is only incremented once and will always be 1.
Even if the condition were replaced with some unpredictable function call, in the worst case it would be true every time, yielding valid==8 at the end of the loop, which should still be alright?
Additionally, I have thus far made the following observations:
The warning is not produced at lower optimization levels, on gcc <=11 or on clang.
Interestingly, the warning is also not produce with array sizes >8 or <6, only for sizes 6,7, and 8.
When I remove the condition inside the loop body(the "if(i==0)", to increment every time and always yield valid==8), the warning disappears.
When I add the condition before the sort call(and thereby provide the compiler with an additional hint about the limits of valid), the warning disappears.
Especially the latter two make me believe I might have managed to confuse gcc's analysis somehow, but also make me question if I am overlooking something obvious or managed to introduce some subtle undefined behaviour in my code.
Am I misunderstanding something in my sleep deprived state or did I encounter a genuine, mostly harmless, compiler bug?
It is indeed a compiler bug, as can be seen in this bugzilla report, which contains almost identical code to the one in my question.
Thanks to Marc Glisse for providing this link to a lot of similar bugs and thereby helping me track down the relevant one.
This code does not compile, using Boost 1.48 and GCC:
// const char* left, const char* right
boost::filesystem::path p = boost::filesystem::absolute(
boost::filesystem::path(right, boost::filesystem::native), // line 314
boost::filesystem::path(left, boost::filesystem::native) ); // line 315
Error messages:
LoggerImplementation.cpp|314|error: invalid conversion from ‘bool (*)(const std::string&)’ to ‘void*’
LoggerImplementation.cpp|314|error: initializing argument 2 of ‘boost::filesystem3::path::path(const Source&, typename boost::enable_if<boost::filesystem3::path_traits::is_pathable<typename boost::decay<Source>::type>, void>::type*) [with Source = const char*]’
LoggerImplementation.cpp|315|error: invalid conversion from ‘bool (*)(const std::string&)’ to ‘void*’
LoggerImplementation.cpp|315|error: initializing argument 2 of ‘boost::filesystem3::path::path(const Source&, typename boost::enable_if<boost::filesystem3::path_traits::is_pathable<typename boost::decay<Source>::type>, void>::type*) [with Source = const char*]’
Under MSVC it compiles. How can I fix this?
Your second argument (boost::filesystem::native) is wrong. boost::filesystem::path simply doesn’t have a constructor which takes this argument – leave it off and the code compiles.
In fact, boost::filesystem::native is a function, and using it in the manner you tried makes no sense. Furthermore, if MSVC compiles this code, that’s a definitive bug (it is using an implicit conversion from a function pointer to void*, which doesn’t exist according to the standard).
i'm using gcc 4.6.2.
I'm trying to push_back in a vector shared_ptr's.
But gcc gives me everytime an error.
Here my codelines:
std::vector< std::tr1::shared_ptr<Process> > procs;
std::string line;
while (getline(file, line) && line.find(JobMask) != std::string::npos)
{
std::string procName = line.substr(line.find(JobMask) + JobMask.size());
std::vector<Instruction> procInstructions = extractProgram(file);
std::queue<int> procInputs = extractInputs(file);
if (!procInstructions.empty())
procs.push_back(std::make_shared<Process>(Process(procName, procInputs, procInstructions))); //line 51
}
return procs;
The Error my gcc is giving is:
Process.cpp: In static member function 'static std::vector<std::tr1::shared_ptr<RMMIX::Process> > RMMIX::Process::createProcesses(const string&)':
Process.cpp:51:95: error: no matching function for call to 'std::vector<std::tr1::shared_ptr<RMMIX::Process> >::push_back(std::shared_ptr<RMMIX::Process>)'
Process.cpp:51:95: note: candidates are:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:826:7: note: void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = std::tr1::shared_ptr<RMMIX::Process>, _Alloc = std::allocator<std::tr1::shared_ptr<RMMIX::Process> >, std::vector<_Tp, _Alloc>::value_type = std::tr1::shared_ptr<RMMIX::Process>]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:826:7: note: no known conversion for argument 1 from 'std::shared_ptr<RMMIX::Process>' to 'const value_type& {aka const std::tr1::shared_ptr<RMMIX::Process>&}'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:839:7: note: void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = std::tr1::shared_ptr<RMMIX::Process>, _Alloc = std::allocator<std::tr1::shared_ptr<RMMIX::Process> >, std::vector<_Tp, _Alloc>::value_type = std::tr1::shared_ptr<RMMIX::Process>]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/bits/stl_vector.h:839:7: note: no known conversion for argument 1 from 'std::shared_ptr<RMMIX::Process>' to 'std::vector<std::tr1::shared_ptr<RMMIX::Process> >::value_type&& {aka std::tr1::shared_ptr<RMMIX::Process>&&}'
In my eyes the error say's, that std::make_shared create a std::shared_ptr.
But in gcc shared_ptr is in the namespace std::tr1.
How could i fix it?
If I understand correctly, make_shared is new in C++11 and is in namespace std, but it is only available if you compile with -std=gnu++0x or similar. But if you do that, then shared_ptr is also in std.
The problem is that there is another version of shared_ptr in std::tr1, but in C++11 mode you should not use it: it should be considered deprecated.
Your solution is simply to remove every use of tr1 and use the full C++11 version of these classes.
C++ template error message can be a beast to read. But the answer is in the 2nd note.
no known conversion for argument 1 from 'std::shared_ptr<RMMIX::Process>' to 'const value_type& {aka const std::tr1::shared_ptr<RMMIX::Process>&}'
The problem is you're using std::make_shared (which creates a std::shared_ptr) and passing it into a vector of std::tr1::shared_ptr.
The simplest solution is drop the TR1. The stuff from the TR1 was some of first features implemented by compilers when adding C++11 support.
std::vector< std::shared_ptr<Process> > procs;
If you are unable to stop using std::tr1::shared_ptr. You'll have to forgo using make_shared as it was not part of the TR1.
When programming in c++ STL, or intensively using 'templatization', and some compiling error happens, often the error report is really long, and often too much not needed information is given.
I'm talking about gcc, i don't know if with other compilers is different, but some times even for just a typo, it takes a while to catch the error purging the
<ns::type<ns::type<ns::type, ns::type<...><ns::type<...> > > > >
I'm looking for some compiler flag, trick, workaround or methodology ( i currently copy past the error and put on two lines what i have and what compiler use to want and removing variables bookmarks... (kinda sad procedure for a not-so-uncommon ctrl+s non well performed)) that could make this task quicker or just helping me ( even only some IDE error syntax highlight... )
STLFilt: An STL Error Message Decryptor for C++ is a popular tool to filter these verbose error messages and turn them into something more legible.
From their website:
STLFilt was initially conceived as a teaching aid, to allow students
taking C++ and/or STL-specific workshops to make sense of typically
overbloated STL error messages. Today, however, even some C++ experts
have adopted STLFilt for use in everyday development. The results may
not always be perfect, but most of the time the information lost
during Decryption is not critical to the application being debugged.
The rest of the time, Decryption is easy enough to bypass.
The distribution for each platform (compiler/library set) is
self-contained and tuned to the idiosyncrasies of that platform. Each
Perl script performs basic regex substitutions for all the standard
(and extended, if present in the library) STL components, while
certain versions of the script go further with respect to message
ordering, line wrapping, library header error treatment, etc., as I
unilaterally deemed appropriate for that platform.
Here's a demo run that shows how it can be useful:
The source program:
#include <map>
#include <algorithm>
#include <cmath>
const int values[] = { 1,2,3,4,5 };
const int NVALS = sizeof values / sizeof (int);
int main()
{
using namespace std;
typedef map<int, double> valmap;
valmap m;
for (int i = 0; i < NVALS; i++)
m.insert(make_pair(values[i], pow(values[i], .5)));
valmap::iterator it = 100; // error
valmap::iterator it2(100); // error
m.insert(1,2); // error
return 0;
}
First, an unfiltered run using the MinGW gcc 3.2 compiler:
d:\src\cl\demo>c++2 rtmap.cpp
rtmap.cpp: In function `int main()':
rtmap.cpp:19: invalid conversion from `int' to `
std::_Rb_tree_node<std::pair<const int, double> >*'
rtmap.cpp:19: initializing argument 1 of `std::_Rb_tree_iterator<_Val, _Ref,
_Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*) [with _Val =
std::pair<const int, double>, _Ref = std::pair<const int, double>&, _Ptr =
std::pair<const int, double>*]'
rtmap.cpp:20: invalid conversion from `int' to `
std::_Rb_tree_node<std::pair<const int, double> >*'
rtmap.cpp:20: initializing argument 1 of `std::_Rb_tree_iterator<_Val, _Ref,
_Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*) [with _Val =
std::pair<const int, double>, _Ref = std::pair<const int, double>&, _Ptr =
std::pair<const int, double>*]'
E:/GCC3/include/c++/3.2/bits/stl_tree.h: In member function `void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::insert_unique(_II,
_II) [with _InputIterator = int, _Key = int, _Val = std::pair<const int,
double>, _KeyOfValue = std::_Select1st<std::pair<const int, double> >,
_Compare = std::less<int>, _Alloc = std::allocator<std::pair<const int,
double> >]':
E:/GCC3/include/c++/3.2/bits/stl_map.h:272: instantiated from `void std::map<_
Key, _Tp, _Compare, _Alloc>::insert(_InputIterator, _InputIterator) [with _Input
Iterator = int, _Key = int, _Tp = double, _Compare = std::less<int>, _Alloc = st
d::allocator<std::pair<const int, double> >]'
rtmap.cpp:21: instantiated from here
E:/GCC3/include/c++/3.2/bits/stl_tree.h:1161: invalid type argument of `unary *
'
And a filtered run using the gcc-specific Proxy c++:
d:\src\cl\demo>c++ rtmap.cpp
*** {BD Software Proxy c++ for gcc v3.01} STL Message Decryption is ON! ***
rtmap.cpp: In function `int main()':
rtmap.cpp:19: invalid conversion from `int' to `iter'
rtmap.cpp:19: initializing argument 1 of `iter(iter)'
rtmap.cpp:20: invalid conversion from `int' to `iter'
rtmap.cpp:20: initializing argument 1 of `iter(iter)'
stl_tree.h: In member function `void map<int,double>::insert_unique(_II, _II)':
[STL Decryptor: Suppressed 1 more STL standard header message]
rtmap.cpp:21: instantiated from here
stl_tree.h:1161: invalid type argument of `unary *'
STL Decryptor reminder:
Use the /hdr:L option to see all suppressed standard lib headers
[Note: demo runs were performed in an 80-column console window with
STLFilt's intelligent line wrapping enabled, and with internal
switches set to produce messages as terse as possible. More detail is
available by tailoring the Decryptor's options.]
The only downside I can see is that it mislabels the C++ Standard Library. :(
Here's a relevant journal article by STLFilt's author.
A few people have made tools to perform this, as there's nothing inbuilt. Tonnes on Google, but the top result returns: http://www.bdsoft.com/tools/stlfilt.html
It should be compatible with visual studio and gcc.
edit::
I need to type less to actually get input in time :)
I need to (de)serialize data on both Windows and Linux (and transfer the files in between). I wanted to use the portable binary archives of Boost's serialization library which can be found in the examples, see e.g. at http://boost-doc-zh.googlecode.com/svn-history/r380/trunk/libs/serialization/example/
This works fine on Windows (VS 2008) but fails to compile under GCC 4.3.2 with the following errors.
Can anybody suggest a solution?
Thanks a lot!
/projects/lib/BOOST/1_44_0/include/boost/archive/basic_archive.hpp: In member function 'void portable_binary_iarchive::init(unsigned int)':
/projects/lib/BOOST/1_44_0/include/boost/archive/basic_archive.hpp:78: error: 'uint_least32_t boost::archive::version_type::t' is private
/home/myfolder/src/portable_binary_iarchive.cpp:92: error: within this context
/home/myfolder/src/portable_binary_iarchive.hpp: In member function 'void portable_binary_iarchive::load(T&) [with T = boost::archive::class_id_type]':
/projects/lib/BOOST/1_44_0/include/boost/archive/detail/iserializer.hpp:107: instantiated from 'static void boost::archive::load_access::load_primitive(Archive&, T&) [with Archive = portable_binary_iarchive, T = boost::archive::class_id_type]'
/projects/lib/BOOST/1_44_0/include/boost/archive/detail/iserializer.hpp:356: instantiated from 'static void boost::archive::detail::load_non_pointer_type<Archive>::load_primitive::invoke(Archive&, T&) [with T = boost::archive::class_id_type, Archive = portable_binary_iarchive]'
/projects/lib/BOOST/1_44_0/include/boost/archive/detail/iserializer.hpp:433: instantiated from 'static void boost::archive::detail::load_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = boost::archive::class_id_type, Archive = portable_binary_iarchive]'
/projects/lib/BOOST/1_44_0/include/boost/archive/detail/iserializer.hpp:586: instantiated from 'void boost::archive::load(Archive&, T&) [with Archive = portable_binary_iarchive, T = boost::archive::class_id_type]'
/projects/lib/BOOST/1_44_0/include/boost/archive/detail/common_iarchive.hpp:66: instantiated from 'void boost::archive::detail::common_iarchive<Archive>::load_override(T&, int) [with T = boost::archive::class_id_type, Archive = portable_binary_iarchive]'
/home/myfolder/src/portable_binary_iarchive.hpp:140: instantiated from 'void portable_binary_iarchive::load_override(T&, int) [with T = boost::archive::class_id_type]'
/projects/lib/BOOST/1_44_0/include/boost/archive/detail/interface_iarchive.hpp:60: instantiated from 'Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = boost::archive::class_id_type, Archive = portable_binary_iarchive]'
/projects/lib/BOOST/1_44_0/include/boost/archive/detail/common_iarchive.hpp:51: instantiated from 'void boost::archive::detail::common_iarchive<Archive>::vload(boost::archive::class_id_type&) [with Archive = portable_binary_iarchive]'
/home/myfolder/src/portable_binary_iarchive.cpp:128: instantiated from here
/home/myfolder/src/portable_binary_iarchive.hpp:107: error: call of overloaded 'class_id_type(intmax_t&)' is ambiguous
/projects/lib/BOOST/1_44_0/include/boost/archive/basic_archive.hpp:118: note: candidates are: boost::archive::class_id_type::class_id_type(size_t)
/projects/lib/BOOST/1_44_0/include/boost/archive/basic_archive.hpp:115: note: boost::archive::class_id_type::class_id_type(int)
Not really a direct answer to your question, but I've had a lot of success with Google's Protocol Buffers. They use them internally and open sourced them: http://code.google.com/p/protobuf/
I built with g++ 4.1.2 and it works fine. I hate bjam, it's hard to see what is happening, and it's unbelievably slow.
There was a warning about a deprecated header, and since this has the earmarks of a deprecated friend declaration, I was hoping to see something old, but I don't.
Did you build it with bjam or did you try to pull out the serialization into your own directory and do it yourself? Because your directory structure is not exactly like the one they have in the package.
#define private public
ought to get rid of the first error about accessing private members. It's a bit cheeky! But it can work as a temporary fix until you've understood the whole program better.