__GLIBC_HAVE_LONG_LONG define has been dropped from glibc in 2.17

[pmachata@…]

Boost uses this define to decide whether it can import ::uint64_t into the boost namespace. In glibc 2.17, that define has been dropped, support for long long is always assumed, and uint64_t is always defined. It is possible to use the macro GLIBC_PREREQ (defined I think since 2.2) to test glibc version.

[pmachata@…]

Since Trac won't let me attach the patch (it finds URLs in there and thinks it's spam; captcha shows, but it doesn't upload anyway for some reason), please get it there: ​http://pmachata.fedorapeople.org/boost-1.53.0-__GLIBC_HAVE_LONG_LONG.patch

[John Maddock]

(In [84950]) Patch for recent versions of glibc which always assume int64_t support. Fixes #8731.

[anonymous]

Your patch didn't work for me - gcc-4.7 Mingw choked on the use of __GLIBC_PREREQ, changed to check for version numbers the old way.

[anonymous]

The patch in ​https://svn.boost.org/trac/boost/changeset/84950 will break when (if) glibc issues version 3.0.

The following patch is preferred way to spell "glibc-2.17 or above":

-#if defined(BOOST_HAS_STDINT_H) && (!defined(__GLIBC__) || defined(__GLIBC_HAVE_LONG_LONG))
+#if defined(BOOST_HAS_STDINT_H) && (!defined(__GLIBC__) \
+                                    || defined(__GLIBC_HAVE_LONG_LONG) \
+                                    || __GLIBC_PREREQ(2, 17))