On 9 Nov 01, at 12:35, J. David Bryan wrote:
On 7 Nov 2001, at 11:38, Prof. A Olowofoyeku wrote:
You basically have a broken gpc installation. Your gcc version ("2.95.3-5") does not match your gpc version ("2.95.3").
I'm not sure I see why this should be considered a requirement. This would imply that if I wanted to test out GPC compilers based on 2.95.3, 2.95.2, and 2.8.1, I would need to install corresponding implementations of GCC,
Correct.
just to have, e.g., "collect2" in the right places.
Not just for collect2.
That does not seem reasonable.
Reasonable or not, that is the way it is.
I understand that GPC defaults to looking the in the same place for all tools, but that should be alterable by environment settings, and doing so should not be considered "fixing a broken installation." It's merely creating an *alternate* installation.
Perhaps. Whether it is a broken or alternate installation is not the important thing. The important thing is that something needs to be done, and just setting the currently available environment variables may not do the job.
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?
That functionality is already present with GCC_EXEC_PREFIX.
As far as I understand, it isn't - or maybe my understanding is just wrong. IIRC, GCC_EXEC_PREFIX does not tell you anything about the GCC version. The path specified in it normally ends in 'gcc-lib/'. The compiler then seems to append the target machine (e.g., "i686-pc-cygwin/") and the target gcc version (e.g., "2.95.3-2") as the place to find its other executables.
Assuming the installed gcc version is 2.95.3 - this then means "..../gcc-lib/i686-pc-cygwin/2.95.3-2/"
Assuming your gpc is based on gcc 2.95.2 - this then means that gpc is looking in: "..../gcc-lib/i686-pc-cygwin/2.95.2/"
In this case, if my understanding is correct, then setting GCC_EXEC_PREFIX gets you nowhere - because the target version that ends the concatenated path still points to "2.95.2". It seems that GCC_EXEC_PREFIX is useful only if (for example), your gpc is installed in "/usr/local/" but your gcc is in "/gcc/" (i.e., different *base* directories). This means that different compiler versions is not catered for at all, and you need a different solution for this.
Frank, am I right in this?
If the directory paths were correct, then gpc would probably have used your gcc "specs" file instead of its own.
But then that would have caused another problem. There are (or at least were, the last time I checked) Cygwin-specific parameters in the specs file supplied with the Cygwin version of GCC, e.g., "%q". GPC will choke on these.
I don't know how the "specs" file is built. But isn't it the case that this is built from the same place as the gcc specs file is built?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com