Re: [MiNT] gcc 4.2.2 build problem

[Alan Hourihane <alanh@fairlite.demon.co.uk>]

On Tue, 2007-12-11 at 23:14 +0100, Vincent Rivière wrote:
> > The way I understood fixincludes anyway, is that it won't install any
> > fixed includes if it doesn't need to. If it does, then it's pointing out
> > possible problems in mintlib that should be fixed.
> > 
> > So I don't see any reason to disable that stage as it actually may help
> > to identify problems in mintlib's includes.
> 
> I remember now.
> The old patches had :
> # Don't run fixproto
> STMP_FIXPROTO =
> 
> I added :
> STMP_FIXINC =
> because I thought it was useless (or harmful), too.
> 
> However, you're right, most targets don't disable these features and we 
> should do the same. I've just recompiled everything after removing the 
> two STMP lines. The only difference is that the file 
> lib/gcc/m68k-atari-mint/4.2.2/include/syslimits.h is now present - just 
> the one causing your problem !
> 
> That file contains :
> /* syslimits.h stands for the system's own limits.h file.
>     If we can use it ok unmodified, then we install this text.
>     If fixincludes fixes it, then the fixed version is installed
>     instead of this text.  */
> 
> #define _GCC_NEXT_LIMITS_H    /* tell gcc's limits.h to recurse */
> #include_next <limits.h>
> #undef _GCC_NEXT_LIMITS_H
> 
> 
> Because I am curious, I tried to compile a single program with #include 
> <syslimits.h>. It fails with : "error: no include path in which to 
> search for limits.h". It fails with the same error if I compile that 
> program with the native Linux gcc ! I don't know how this file can be 
> useful.

It's there for GCC's internal use. It's not a standard #include.

> About the fixincludes stuff : now the directory "fixincludes" is built, 
> but it seems that it is never run. I can hardly imagine how the includes 
> could be fixed during my build process, because I compile GCC and the 
> MiNTLib separately. I know the right way to build GCC should be some 
> kind of "bootstrap" building everything in one pass, but I didn't manage 
> to do it. Maybe compiling GCC that way, the includes get somehow fixed ?

Yes, I believe you have to compile GCC in multiple passes to do the fix
properly.

> Anyway, in my next official build, I'll un-disable fixincludes, because 
> it is more standard, and harmless.

O.k. thanks.

> Thank you for pointing me to this, and great job for having found the 
> problem.

O.k.

Alan.