Bug 977098 - Disagreement over type of boost::uint64_t
Disagreement over type of boost::uint64_t
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: boost (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Machata
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-23 10:22 EDT by Tom Hughes
Modified: 2015-05-04 21:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-26 11:09:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program (433 bytes, text/x-c++src)
2013-06-23 10:22 EDT, Tom Hughes
no flags Details

  None (edit)
Description Tom Hughes 2013-06-23 10:22:16 EDT
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 16:15:05 EDT
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 11:09:58 EDT
The patch is now in Rawhide.  Since this just reinstates the old behavior, it shouldn't lead to ABI breakages.

Note You need to log in before you can comment on or make changes to this bug.