https://svn.boost.org/trac10/ticket/2354 <p> In boost 1.35 on Linux on x86-64 an attempt to serialize any of the STL collections produces multiple definitions of "implementation_level&lt;long int&gt;". Eventually I tracked these to the int64_t handling in collection_traits.hpp, where the following code appears: </p> <blockquote> <p> <em> determine if its necessary to handle (u)int64_t specifically </em> i.e. that its not a synonym for (unsigned) long <em> if there is no 64 bit int or if its the same as a long </em> we shouldn't define separate functions for int64 data types. #if defined(BOOST_NO_INT64_T) \ </p> <blockquote> <table class="wiki"> <tr><td> (ULONG_MAX != 0xffffffff &amp;&amp; ULONG_MAX == 18446744073709551615u) <em> 2<strong>64 - 1 </strong></em></td></tr></table> </blockquote> <p> # define BOOST_NO_INTRINSIC_INT64_T #endif </p> </blockquote> <p> The bug is that the lengthy constant is just "u", and so will be compiler-truncated to unsigned int, 4 bytes on this platform, and so will fail to be equal to the 8-byte ULONG_MAX. Changing the "u" to "ul" fixes the bug. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/2354 Trac 1.4.3 Robert Ramey Sun, 21 Sep 2008 20:48:07 GMT https://svn.boost.org/trac10/ticket/2354#comment:1 https://svn.boost.org/trac10/ticket/2354#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> I've fixed in my local copy. Assuming testing is successful, it will migrate to the release. </p> Ticket