[Box Backup] LLONG_MAX configure mistake with gcc 4.1.1 (Linux)
Fri, 16 Jun 2006 00:28:51 +0100
Yes, there's definitely a difference because my Gentoo system doesn't
find the definitions for LLONG_MAX during configure and then goes on to
try to determine its own (where this GCC 4.1.1 behaviour then causes
I've got limits.h (two versions of it - seems to be one 'public' one in
/usr/include and one GCC private version in
/usr/lib/gcc/i386-pc-linux-gnu/4.1.1/include/limits.h), and they do
contain the definition of LLONG_MAX/MIN so I'll need to try to track
down the header processing to understand the reason those symbols aren't
defined on my system.
Whilst it might not hit as many people as I first thought, I'm still
pretty convinced it won't compile for people with GCC 4.1.1 if they
don't have the definitions for LLONG_MAX and LLONG_MIN (as seems to be
the case on my Gentoo Linux).
Anyway, it's late so I'll think this over for a while.
Martin Ebourne wrote:
> On Thu, 2006-06-15 at 21:00 +0100, Stuart Hickinbottom wrote:
>> I've done some more investigation and I believe GCC 4.1 is applying
>> optimisations (whether or not you pass -O<anything>) that cause the
>> sanity check of the determined/compiler-supplied LLONG_MIN/LLONG_MAX to
>> always fail.
> I'm using FC5, gcc 4.1.1, x86_64. The test program fails here too. Quite
> scary actually. The gcc compiler aborts(!) but g++ compiles it. If I
> compile to assembler then two of the four "sanity fail" strings don't
> even appear in the output, this with optimisation off! I only really do
> sparc, arm, and m68k programming so I don't really know what's going on
> in the assembler code and can't really be bothered to try and figure it
> But Box configures and compiles ok:
> Note that it's not running the program, it's finding the definitions in
> limits.h. How come they're missing on your system?
> Seems gcc is reassuringly broken though.
> boxbackup mailing list