On 10 Nov 01, at 1:02, J. David Bryan wrote:
On 10 Nov 2001, at 5:46, Frank Heckenbach wrote:
The proper things to do, as far the "GCC philosophy" is concerned, is to install the matching GCC version. Period.
But the issue with respect to Cygwin is that there *is* no matching version. Cygwin doesn't provide a gcc-2.95.3, only a gcc-2.95.3-1, -2, etc.
There was - at least for gcc releases up to and including gcc-2.95.2. In the past, dashes were reserved for pre-release snapshots, and not for "standard" releases. I have no idea why those who now build gcc under Cygwin (and Mingw) use the dashes. It seems pretty non- standard to me, as I have never seen any such thing on any system other than Windows. They will have their own reasons of course, but this doesn't make it easier for gpc users. This problem will disappear when gpc becomes integrated with gcc.
These versions include patches necessary to get GCC to build on Cygwin (I presume -- I haven't tried to build the FSF version of gcc- 2.95.3, but I can think of no other reason why Cygnus would want to maintain a version separate from the FSF version).
There is no problem with building gcc under Cygwin. The FSF sources (right up to the latest gcc) build just fine. The Win32 guys add some patches, not for gcc to build, but to cater for certain things that they think are necessary under Win32. These things may indeed be necessary for hard core C programmers, but I have never needed them, and I do not use the "official" Cygwin gcc binary distributions at all (partly because of the weird dashes). Yet, I do not have any problem building gcc (right up to the latest 3.x) or gpc under Cygwin.
So unless GPC is going to start providing patches to the Cygnus "dash versions" of the GCC sources, so that GPC can be built on gpc-2.95.3-x, there cannot be matching versions of GPC and GCC under Cygwin.
There can be. You can edit "Makefile" after building gpc, change "gcc_version=2.95.3" to "gcc_version=2.95.3-5" or whatever, touch all the files, delete xgpc.exe, and rebuild just the driver program again ("make xgpc.exe"). Sounds longwinded but it takes less than 10 seconds to complete all this - and it can be put in a script. Indeed, there may be an easy way to change the "gcc_version" just by passing arguments to the C compiler when building the driver. I know that "-DDEFAULT_TARGET_VERSION" is passed (by "make") to the compiler when building the driver.
All of copying/linking the missing files, setting any environment variables, or using special options is "fixing a broken installation".
I would argue that it's much too restricted a view to call any installation that relies on environment variables or special options "broken." Surely if that's the GCC view, then why provide these variables and options at all?
Perhaps because, on many systems, users do not have write access to the "/usr" directory - and, in such cases, unless they can convince the sys admins to install stuff for them, they will be stuck. With the environment variables, they can at least do something for themselves.
Is it broken if I install a cross-compiler and therefore need to use the "-b" option?
A cross compiler is a different thing. You are not trying to run the compiler that you build on the cross compiler system.
Is it broken if I choose to use a more reasonable directory structure under Windows (where "/usr" has no meaning) and therefore need to use environment variables?
Yes. It is not only gcc/gpc that may want things to be in such a directory structure. Cygwin is supposed to be a "unix under Windows" thing. As such, it makes plenty of sense to use the standard unix directory structures, else things will break. Try for example to install XFree86 under Cygwin to a different directory structure, and see. The more things get ported from linux/unix to Cygwin, the more trouble you will have if you choose to ignore the "/usr" structure (at least, if you want to use those things).
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