[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
I added :
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 */
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
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