Prof. A Olowofoyeku (The African Chief) wrote:
Frank, is there a cleaner solution to all this? For example, can we introduce an optional environment variable which the gpc driver program will look for (e.g., "INSTALLED_GCC_VERSION=2.95.3-5") and then be able to find the other executables that it needs?
I can of course patch gpc.c myself to do this under Cygwin and Mingw - but it might be useful for other platforms as well.
The problem with GPC_EXEC_PREFIX and GCC_EXEC_PREFIX is that only one directory can be given (even if both are set, the former takes precedence), so if the GPC and GCC files are in different directories, this won't work.
However, I just found that it also recognizes the variables COMPILER_PATH (for cpp and cc1) and LIBRARY_PATH (for libgcc.a), so if both are set to the GCC lib directory, it should work (I hope).
They even support multiple directories, separated with PATH_SEPARATOR (which is `:' on Unix, might be `:' or `;' on Cygwin and Mingw), but GPC's default directory is searched in addition, anyway, so it should be enough to point them just to the GCC directory.
To the African Chief, maybe it would be nice to add some script that could find out in which mode the /usr/local/lib/.... dir is mounted and modify specs files accordingly !
This is a red herring. Like I said, the real cause of your problems has been identified above. If the directory paths were correct, then gpc would probably have used your gcc "specs" file instead of its own.
I don't know if it's a real issue, but if it helps we could just ignore CRs in the specs file. AFAICS, CRs shouldn't ever serve any useful purpose there, so it shouldn't do any harm anywhere. You might want to try the attached patch and tell me if it works and if it's needed. (If so, you might want to submit the same patch to the GCC developers for gcc.c ...)
Frank