[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] gcc 4.2.2 build problem

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.
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 ?
Anyway, in my next official build, I'll un-disable fixincludes, because it is more standard, and harmless.
Thank you for pointing me to this, and great job for having found the problem. 

Vincent