Bug 977098
Summary: | Disagreement over type of boost::uint64_t | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tom Hughes <tom> | ||||
Component: | boost | Assignee: | Petr Machata <pmachata> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | bkoz, denis.arnaud_fedora, mnewsome, pertusus, pmachata | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-06-26 15:09:58 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
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: https://svn.boost.org/trac/boost/ticket/8731 The patch is now in Rawhide. Since this just reinstates the old behavior, it shouldn't lead to ABI breakages. |
Created attachment 764315 [details] Test program 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.