Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk