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 [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
