libcdr-0.1 fails to compile with boost 1.59.0

[David Evans]

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