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;
typedef long long int int64_t;
But (on one #ifdef branch) sys/types.h says:
# ifdef __GNUC__
__extension__ typedef long long int int64_t;
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk