libcdr-0.1 fails to compile with boost 1.59.0

[David Evans]

On 8/27/15 8:12 AM, David Evans wrote:
> On 8/27/15 1:27 AM, Ryan Schmidt wrote:
>> Hi Dave,
>>
>> I'll file this in Trac once I can reach it again, but I wanted to let you know that libcdr-0.1 fails to build with boost 1.59.0:
>>
>>
>> Undefined symbols for architecture x86_64:
>>   "boost::system::system_category()", referenced from:
>>       __GLOBAL__sub_I_CDRParser.cpp in CDRParser.o
>>   "boost::system::generic_category()", referenced from:
>>       __GLOBAL__sub_I_CDRParser.cpp in CDRParser.o
>> ld: symbol(s) not found for architecture x86_64
>>
>>
>>
>>
> 
> Thanks, Ryan.  This is the same problem that caused the libvisio breakage that Mihai reported on the devel list.  I was
> just going to add a ticket myself to commemorate the problem since it may have wider implications.  If you will post
> this ticket when you can, I will respond to it
> 
> The issue is that in boost 1.59, a number of symbols have been renamed to conform to C++ committee usage.  To ease
> migration to the new names, the old names are still available but deprecated and the old symbols are automatically
> replaced by the new ones.
> 
> See http://www.boost.org/doc/libs/1_59_0/libs/system/doc/reference.html#Deprecated-names
> 
> The problem is that, in some cases, old symbols that were static consts are now replaced by function calls.  In
> particular, <boost/system/error_code.hpp> constains the following code
> 
> # ifndef BOOST_SYSTEM_NO_DEPRECATED
>     inline const error_category &  get_system_category() { return system_category(); }
>     inline const error_category &  get_generic_category() { return generic_category(); }
>     inline const error_category &  get_posix_category() { return generic_category(); }
>     static const error_category &  posix_category = generic_category();
>     static const error_category &  errno_ecat     = generic_category();
>     static const error_category &  native_ecat    = system_category();
> # endif
> 
> Because of the three assignment statements at the end of this block, any code that includes
> <boost/system/error_code.hpp> either directly or indirectly will introduce calls to generic_category() and
> system_category().
> 
> So if a code module includes this header and does not include -lboost_system-mt in its LDFLAGS a missing symbol error is
> generated at link time as you have found.  This can occur even if these functions or the old equivalents are not used in
> the code module at all!
> 
> As Mihai has done for libvisio-0.1, the correct solution seems to be to use to define BOOST_SYSTEM_NO_DEPRECATED to
> suppress this compatibility block in <boost/system/error_code.hpp>.
> 
> Using  BOOST_SYSTEM_NO_DEPRECATED also means that if a code module DOES use the old names, it needs to be converted to
> the new ones to avoid breakage.  The Boost.System documentation specifically mentions
> 
> generic_category -> generic_category()
> system_category -> system_category()
> 
> as breaking changes that need to be fixed in any case since these changes effect usage without a making name change and
> could not therefore be included in the deprecation aliases.  BOOST_SYSTEM_NO_DEPRECATED will not help here.
> 
> I've seen the same problem with librevenge itself and there are probably others. I'm checking all the librevenge based
> ports now but it looks like any code that includes a boost header and doesn't link with -lboost_system_mt will have this
> problem.
> 
> Copying this to the devel list as a heads up for others.
> 
> Dave
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 

Just to clarify, code modules that DO directly use one of the deprecated symbols are unlikely to experience this problem
since they presumably link against libboost_system-mt already.

Dave