Re: [boost] int64_t/boost/gcc 2.95.3

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-06-22 16:30:42

John Max Skaller wrote:
> 
> 0. My system is linux/gcc 2.95.3.pentium:
> 
>         g++ -Wno-long-long -pedantic -ansi -shared -Iboost_1_22_0 ...

What is your versioh of glibc?
(find out with "ldd --version")

> 6. /usr/include/stdint.h exists, and it defines (u)int64_t

Note that the definition of (u)int64_t is not (primarily) a
feature of your compiler, but of your standard library.  On
Linux, these are separate things.

There is also a definition of (u)intXX_t in /usr/include/sys/types.h,
at least here on glibc 2.2.3.  Unfortunately, for (u)int64_t, these
definitions are slightly different.  In particular,
stdint.h says (note the absence of any dependency on __GNUC__):

# if __WORDSIZE == 64
typedef long int                int64_t;
# else
__extension__
typedef long long int           int64_t;
# endif

But (on one #ifdef branch) sys/types.h says:

#  ifdef __GNUC__
__extension__ typedef long long int int64_t;
#  endif

That means when using non-gcc compilers with these headers,
it depends on the order of #include's (sys/types.h first or
stdint.h first) whether int64_t is available or not.  I
therefore decided not to depend on stdint.h.

Also, when I first tried to use glibc's stdint.h, it had
deficiencies so boost/cstdint.hpp was actually a better
choice.
 
> 8. There is a complicated set of conditions deciding how to
>    define (u)int64_t which I don't understand, but it
>    isn't being defined 

The preprocessor conditions look for one of the <limits.h>
macros for "long long". Note that gcc defines these
only when special #defines are given.  Try -D_GNU_SOURCE.

> Long and short: in trying to use boost, I am temporarily
> without recourse other than abandoning (u)int64_t.

Try -D_GNU_SOURCE first, for example at the top (before
any #include) of your source file needing int64_t.

Jens Maurer