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@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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
