hello! there is a nasty little bug in cppdefault.c in gcc 4.0.3: wrong: const char cpp_GCC_INCLUDE_DIR[] = GCC_INCLUDE_DIR; const size_t cpp_GCC_INCLUDE_DIR_len = sizeof GCC_INCLUDE_DIR - 8; correct: const char cpp_GCC_INCLUDE_DIR[] = GCC_INCLUDE_DIR; const size_t cpp_GCC_INCLUDE_DIR_len = sizeof GCC_INCLUDE_DIR - 1; it is also persistent in gcc-4.1.1 effects of this bug: add_standard_paths in c-incpath.c is defeated. therefore standard include headers are not accessed relatively to the executable-path. instead there are accessed with the paths which are build in during configuration. this does not matter if you want to use gcc only in /usr. but if the prefix-dir and the installdir differ you get a problem. this is common on mingw. When GCC_INCLUDE_DIR is shorter than 8 chars you get an even bigger problem because size_t wraps around... in case anybody is interested: i stumbled over this bug by trying to build a position-independent gcc for mingw. to do this, i must hack cppdefault.c: #define GCC_INCLUDE_DIR "/usr/lib/gcc/mingw32/4.0.3/" #define GPLUSPLUS_INCLUDE_DIR "/usr/lib/gcc/mingw32/4.0.3/../../../../include/c++/4.0.3" #define GPLUSPLUS_TOOL_INCLUDE_DIR "/usr/lib/gcc/mingw32/4.0.3/../../../../include/c++/4.0.3/mingw32" #define GPLUSPLUS_BACKWARD_INCLUDE_DIR "/usr/lib/gcc/mingw32/4.0.3/../../../../include/c++/4.0.3/backward" #define LOCAL_INCLUDE_DIR "/usr/lib/gcc/mingw32/4.0.3/include" #undef PREFIX_INCLUDE_DIR #undef CROSS_INCLUDE_DIR #undef TOOL_INCLUDE_DIR #undef SYSTEM_INCLUDE_DIR #define STANDARD_INCLUDE_DIR "/usr/lib/gcc/mingw32/4.0.3/../../../../include" here /usr/lib/gcc/mingw32/4.0.3/ is a dummy which could be anything... . it is replaced later by add_standard_paths. perhaps there is a way to avoide this hack (exec-prefix ??) but i have not tried this jet. greetings, timo
"include" is 7 characters which is what the -8 is for as I understand it. I think you mishacked the cppdefault.c. What is passed to cppdefault always includes "include": -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \ So I think you are incorrect in setting it not to include "include". So we always compare against - the include too: if (!strncmp (p->fname, cpp_GCC_INCLUDE_DIR, len)) Also we need to have the include part for cpp_include_default: #ifdef GCC_INCLUDE_DIR /* This is the dir for fixincludes and for gcc's private headers. */ { GCC_INCLUDE_DIR, "GCC", 0, 0, 0, 0 }, #endif so you mishacked the compiler.
ok. the trick with the "include" which provides additional 7 chars confused me. but the issue remains: I'm not able to produce an position independent gcc for mingw without hacking cppdefaults.c. The reason for this is that the paths for cppdefault.c which are passed on the commandline (-DGCC_INCLUDE_DIR="/mingw/lib/gcc/mingw32/4.0.3/include" -DGPLUSPLUS_INCLUDE_DIR="/mingw/lib/gcc/mingw32/4.0.3/../../../../include/c++/4.0.3" -DGPLUSPLUS_TOOL_INCLUDE_DIR="/mingw/lib/gcc/mingw32/4.0.3/../../../../include/c++/4.0.3/mingw32" ....) are transformed into absolute paths in cppdefaults.o: strings cppdefault.o D:/Programme/timo/msys-new/mingw/lib/gcc/mingw32/4.0.3/include D:/Programme/timo/msys-new/mingw/include/c++/4.0.3 D:/Programme/timo/msys-new/mingw/include/c++/4.0.3/mingw32 D:/Programme/timo/msys-new/mingw/include/c++/4.0.3/backward .... I am using msys. some part of msys is apparently translating paths from mingw-style "/mingw/..." to absolute windows style "D:/...". Till I figured out how to overcome this, I will use the hacked defines in cppdefault.c (but I will use "const size_t cpp_GCC_INCLUDE_DIR_len = sizeof GCC_INCLUDE_DIR - 8" now and append an include to GCC_INCLUDE_DIR). Because this is apparently a bug in msys/mingw, I will ask there and not bother the gcc-bug-list anymore.