Bug 977098

Summary: Disagreement over type of boost::uint64_t
Product: [Fedora] Fedora Reporter: Tom Hughes <tom>
Component: boostAssignee: Petr Machata <pmachata>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: 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:
Description Flags
Test program none

Description Tom Hughes 2013-06-23 14:22:16 UTC
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.

Comment 1 Petr Machata 2013-06-25 20:15:05 UTC
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

Comment 2 Petr Machata 2013-06-26 15:09:58 UTC
The patch is now in Rawhide.  Since this just reinstates the old behavior, it shouldn't lead to ABI breakages.