Red Hat Bugzilla – Bug 977098
Disagreement over type of boost::uint64_t
Last modified: 2015-05-04 21:38:07 EDT
Created attachment 764315 [details]
The attached simple test program using boost::u32regex fails to link on rawhide because it can't find the function:
boost::icu_regex_traits::isctype(int, unsigned long long) const
to demonstrate, compile the attached program with:
g++ -o icu_regex icu_regex.cpp -lboost_regex -licuuc
which will compile and link with F18 and F19 but not on rawhide.
The underlying problem appears to be that boost::uint64_t expands to "unsigned long long" but the mangled function names in libboost_regex.so suggest that it was expanding to "unsigned long" when the library was build, so the symbols no longer match and the program will not link.
In turn I think the cause is that rawhide is inheriting boost from F19 but glibc in rawhide has changed so that it no longer defines __GLIBC_HAVE_LONG_LONG and as a result line 44 of boost/cstdint.hpp no longer matches and a different path is taken resulting in a different definition of boost::uint64_t.
Hmm, right, the DSO's were built when glibc still defined HAVE_LONG_LONG, therefore ::uint64_t was used directly, which, on 64-bit, would be an unsigned long typedef. Later on that define disappeared, and now boost has to typedef it itself, and does so using unsigned long long (which would be the same width, but different type).
Thank you for digging this out. The rationale behind that change seems to be that "long long" is now simply always required with glibc >= 2.17. I'll add a patch to this effect to rawhide. I've also opened an upstream ticket:
The patch is now in Rawhide. Since this just reinstates the old behavior, it shouldn't lead to ABI breakages.