Trying to get strings output for GPC to work, I needed a win32 gpc binary to check my changes to GDB.
But I have problems both with the latest cygwin binary port ftp://agnes.dida.physik.uni-essen.de/home/chief/win32/cygwin/2.95.3/gpc-2001 0924.i686-pc-cygwin.tar.gz
With the latest cygwin tools (uploaded using cygwin setup program) I get a problem that seems related to the fact that the assembler is called without any argument.
$ gpc -v test.p Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release) /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/gpcpp.exe -lang-pascal -v -iprefix /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specsi686-pc-cygwin/2.95.3/ -famtmpfil e=/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc000288 -fdelphi-comments -D__GNU _PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010924 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__= 1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -D_WIN32 -DWINNT -D_X86_=1 -D__STDC__=1 -D_ _stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__d eclspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386__ -D_WIN32 -D__WINNT__ -D_ X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribu te__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386 -D_ _WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -D__CYGWIN32__ -D__CYG WIN__ test.p /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cca00288 GNU Pascal Compiler PreProcessor version 20010924, based on gcc-2.95.3 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specsi686-pc-cygwin/2.95.3/include /usr/local/include /include /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/include /usr/include End of search list. /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/gpc1.exe /cygdrive/c/DOCUME~1/ADMI NI~1/LOCALS~1/Temp/cca00288 -quiet -dumpbase test.pas -version -famtmpfile=/cygd rive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc000288 -o /cygdrive/c/DOCUME~1/ADMINI~1 /LOCALS~1/Temp/ccb00288 GNU Pascal version 2.95.3 20010315 (release) (i686-pc-cygwin) compiled by GNU C version 3.0.1. GNU Pascal version is actually 20010924, based on gcc-2.95.3 20010315 (release) test.p:1: warning: missing program header test.p:2: warning: missing string capacity - assuming 255 as Assembler messages: for reading open : No such file or directory
Administrateur@LAOCOON /home/muller
Remebering that mingw32 is the prefered win32 version, I tried to download the latest gpc for mingw32, but here again, I had problems.
F:\pas\cvs100\ide>gpc -v Reading specs from f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\spec s gpc version 20010623, based on 2.95.3 20010315 (release)
F:\pas\cvs100\ide>gcc -v Reading specs from f:/mingw32/bin/../lib/gcc-lib/mingw32/2.95.3-5/specs gcc version 2.95.3-5 (mingw special)
F:\pas\cvs100\ide>gpc -v --automake hello.pp Reading specs from f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\spec s gpc version 20010623, based on 2.95.3 20010315 (release) f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpcpp.exe -lang-pascal -v -iprefix f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw 32msvc\2.95.3\ -famtmpfile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca01008 -fautomak e -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D_ _GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010623 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__s tdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__ cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__OS_DOS__ =1 -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D __WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___s tdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__d eclspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386 -D__WIN32 -D__WINNT -D___s tdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.pp C:\DOCUME ~1\ADMINI~1\LOCALS~1\Temp\ccb01008 GNU Pascal Compiler PreProcessor version 20010623, based on gcc-2.95.3 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\ f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\2.95. 3\include /usr/local/include /include /usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/include /usr/local/i386-mingw32/include End of search list. f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpc1.exe C:\DOCUME~1\A DMINI~1\LOCALS~1\Temp\ccb01008 -quiet -dumpbase hello.pas -version -famtmpfile=C :\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca01008 -fautomake -o C:\DOCUME~1\ADMINI~1\LO CALS~1\Temp\ccc01008 GNU Pascal version 2.95.3 20010315 (release) (i386-mingw32msvc) compiled by GNU C version 3.0. GNU Pascal version is actually 20010623, based on gcc-2.95.3 20010315 (release) hello.pp:1: warning: missing program header as -o C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccd01008 C:\DOCUME~1\ADMINI~1\LOCALS~1 \Temp\ccc01008 collect2 crt2.o -Lf:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3 C:\D OCUME~1\ADMINI~1\LOCALS~1\Temp\ccd01008 -lgpc -lmingw32 -lgcc -lmoldname -lmsvcr t -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt gpc: installation problem, cannot exec `collect2': No such file or directory
I have the correct gcc installed, but gpc needs collect2, where should I find that binary ?
Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
Some time ago tried to build GPC for i586-mingw32msvc (as usually cross-building under Linux). Some hacking gpc.c were needed to get relative prefix working for native compiler. No much testing done, but I can make my binaries available.
Andris
On Tue, 6 Nov 2001, Pierre Muller wrote:
Trying to get strings output for GPC to work,I needed a win32 gpc binary to check my changes to GDB.
But I have problems both with the latest cygwin binary port ftp://agnes.dida.physik.uni-essen.de/home/chief/win32/cygwin/2.95.3/gpc-2001 0924.i686-pc-cygwin.tar.gz
With the latest cygwin tools (uploaded using cygwin setup program) I get a problem that seems related to the fact that the assembler is called without any argument.
$ gpc -v test.p Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release) /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/gpcpp.exe -lang-pascal -v -iprefix /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specsi686-pc-cygwin/2.95.3/ -famtmpfil e=/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc000288 -fdelphi-comments -D__GNU _PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010924 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__= 1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -D_WIN32 -DWINNT -D_X86_=1 -D__STDC__=1 -D_ _stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__d eclspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386__ -D_WIN32 -D__WINNT__ -D_ X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribu te__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386 -D_ _WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -D__CYGWIN32__ -D__CYG WIN__ test.p /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cca00288 GNU Pascal Compiler PreProcessor version 20010924, based on gcc-2.95.3 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specsi686-pc-cygwin/2.95.3/include /usr/local/include /include /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/include /usr/include End of search list. /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/gpc1.exe /cygdrive/c/DOCUME~1/ADMI NI~1/LOCALS~1/Temp/cca00288 -quiet -dumpbase test.pas -version -famtmpfile=/cygd rive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc000288 -o /cygdrive/c/DOCUME~1/ADMINI~1 /LOCALS~1/Temp/ccb00288 GNU Pascal version 2.95.3 20010315 (release) (i686-pc-cygwin) compiled by GNU C version 3.0.1. GNU Pascal version is actually 20010924, based on gcc-2.95.3 20010315 (release) test.p:1: warning: missing program header test.p:2: warning: missing string capacity - assuming 255 as Assembler messages: for reading open : No such file or directory
Administrateur@LAOCOON /home/muller
Remebering that mingw32 is the prefered win32 version, I tried to download the latest gpc for mingw32, but here again, I had problems.
F:\pas\cvs100\ide>gpc -v Reading specs from f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\spec s gpc version 20010623, based on 2.95.3 20010315 (release)
F:\pas\cvs100\ide>gcc -v Reading specs from f:/mingw32/bin/../lib/gcc-lib/mingw32/2.95.3-5/specs gcc version 2.95.3-5 (mingw special)
F:\pas\cvs100\ide>gpc -v --automake hello.pp Reading specs from f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\spec s gpc version 20010623, based on 2.95.3 20010315 (release) f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpcpp.exe -lang-pascal -v -iprefix f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw 32msvc\2.95.3\ -famtmpfile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca01008 -fautomak e -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D_ _GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010623 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__s tdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__ cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__OS_DOS__ =1 -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D __WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___s tdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__d eclspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386 -D__WIN32 -D__WINNT -D___s tdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.pp C:\DOCUME ~1\ADMINI~1\LOCALS~1\Temp\ccb01008 GNU Pascal Compiler PreProcessor version 20010623, based on gcc-2.95.3 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\ f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\2.95. 3\include /usr/local/include /include /usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/include /usr/local/i386-mingw32/include End of search list. f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpc1.exe C:\DOCUME~1\A DMINI~1\LOCALS~1\Temp\ccb01008 -quiet -dumpbase hello.pas -version -famtmpfile=C :\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca01008 -fautomake -o C:\DOCUME~1\ADMINI~1\LO CALS~1\Temp\ccc01008 GNU Pascal version 2.95.3 20010315 (release) (i386-mingw32msvc) compiled by GNU C version 3.0. GNU Pascal version is actually 20010623, based on gcc-2.95.3 20010315 (release) hello.pp:1: warning: missing program header as -o C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccd01008 C:\DOCUME~1\ADMINI~1\LOCALS~1 \Temp\ccc01008 collect2 crt2.o -Lf:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3 C:\D OCUME~1\ADMINI~1\LOCALS~1\Temp\ccd01008 -lgpc -lmingw32 -lgcc -lmoldname -lmsvcr t -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt gpc: installation problem, cannot exec `collect2': No such file or directory
I have the correct gcc installed, but gpc needs collect2, where should I find that binary ?
Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
On 6 Nov 2001, at 13:39, Pierre Muller wrote:
With the latest cygwin tools (uploaded using cygwin setup program) I get a problem that seems related to the fact that the assembler is called without any argument.
[...]
Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs
[...]
Assembler messages: for reading open : No such file or directory
I have run into this problem before. If I recall correctly, it's a text/binary problem with the "specs" file. See if the specs file listed above has CRLF line endings. If so, change them to LF line endings, and the problem should disappear.
-- Dave
At 18:14 06/11/2001 , J. David Bryan a écrit:
On 6 Nov 2001, at 13:39, Pierre Muller wrote:
With the latest cygwin tools (uploaded using cygwin setup program) I get a problem that seems related to the fact that the assembler is called without any argument.
[...]
Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs
[...]
Assembler messages: for reading open : No such file or directory
I have run into this problem before. If I recall correctly, it's a text/binary problem with the "specs" file. See if the specs file listed above has CRLF line endings. If so, change them to LF line endings, and the problem should disappear.
Yes, thanks a lot ! This indeed worked !
But I still get a problem, cpp0 executable is not found... is that an alias of cpp ??
$ gcc -v Reading specs from /bin/../lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs gcc version 2.95.3-5 (cygwin special)
$ gpc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs gpc version 20010623, based on 2.95.3 20010315 (release)
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 !
Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
On 7 Nov 2001, at 9:53, Pierre Muller wrote:
[...]
But I still get a problem, cpp0 executable is not found... is that an alias of cpp ??
$ gcc -v Reading specs from /bin/../lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs gcc version 2.95.3-5 (cygwin special)
$ gpc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs gpc version 20010623, based on 2.95.3 20010315 (release)
You basically have a broken gpc installation. Your gcc version ("2.95.3- 5") does not match your gpc version ("2.95.3"). So gpc cannot find the files it needs. This is actually the *real* cause of all the problems that you have been experiencing (including with "as"). Also, your gcc and gpc seem to be installed in different places. Until you fix this, you will get other problems - especially when it comes to linking (e.g., it won't find "collect2.exe").
The easiest solution that I can see is to copy cpp0.exe, cc1.exe, and collect2.exe from the gcc "...i686-pc-cygwin/2.95.3-5/" directry to the gpc "...i686-pc-cygwin/2.95.3/" directory. There are other possible solutions - e.g., get (or build) the correct gcc version (i.e., just plain "2.95.3", without the "-1" or "-5" suffixes). Possibly another solution is to set the GCC_EXEC_PREFIX or GPC_EXEC_PREFIX environment variables - but I am not sure whether this will help.
It is a problem for GPC that Cygnus keeps adding these suffixes. I can understand why, and I am sure that they are justified to do so - but it does mean that it is more likely than not, that gcc and gpc versions will not match, unless each person builds gpc for himself to match the exact suffix of the gcc version (and then everytime you upgrade your gcc, you will need to rebuild the gpc driver program).
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.
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.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
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
On 9 Nov 2001, at 4:52, Frank Heckenbach wrote:
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)....
I will investigate more thoroughly over the weekend, but as far as I can see, the "problem" is that GPC is being installed only with a partial set of tools (e.g., no C compiler) and is depending on a prior installation of GCC for the missing parts. This should not cause a problem, except that GPC attempts to locate, for example, the C compiler (cc1) in the same location as GPC was installed. This will not necessarily be correct in the case of separate installations of GCC and GPC. Nor should it be necessary to force these two to reside in the same location.
It would seem to me, therefore, that instead of GPC_EXEC_PREFIX and GCC_EXEC_PREFIX being mutually exclusive, GPC should first search using GPC_EXEC_PREFIX (to locate tools from the GPC installation, e.g., gpc1) and, if the needed tool is not found, then search the GCC_EXEC_PREFIX for tools from the GCC installation, e.g., cc1.
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).
I believe it will, but doesn't this workaround simply fix the existing "improper" implementation of GCC/GPC_EXEC_PREFIX? (I put "improper" in quotes because there may be a good rationale for the existing method that I do not immediately see.)
I don't know if it's a real issue, but if it helps we could just ignore CRs in the specs file.
I believe the situation arises because Cygwin provides user-selected "text" and "binary" mounts for various parts of the emulated Unix directory hierarchy. The mount type defines how Cygwin should handle file reads and writes, i.e., whether files should contain CR-LF or only LF line ends; this is to accommodate file exchange with Windows programs.
The specific problem occurs when "specs" is built in a directory mounted in "text" mode (so the file is generated with CR-LF line ends) but then is copied during the GPC installation process to a directory mounted in "binary" mode. The CR-LF line ends remain in the file (because the file is an exact copy and is not translated when moving between mount types -- "bug" or "feature" is debatable :-), and GPC chokes when it encounters the CRs.
The problem should not occur if only binary mounts are used in Cygwin. Also, it could be solved during GPC installation by copying "specs" in such a way that the source and destination directory mount types are considered.
(If so, you might want to submit the same patch to the GCC developers for gcc.c ...)
I believe that it's only a problem for Cygwin, and then only a problem if the particular directories involved are mounted in different modes, but I'll investigate this a little more and report back later.
-- Dave
On 9 Nov 01, at 12:20, J. David Bryan wrote:
On 9 Nov 2001, at 4:52, Frank Heckenbach wrote:
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)....
I will investigate more thoroughly over the weekend, but as far as I can see, the "problem" is that GPC is being installed only with a partial set of tools (e.g., no C compiler) and is depending on a prior installation of GCC for the missing parts.
As far as I understand, this is the expected thing. IIRC "make pascal.bindist" is what creates the binary distribution, and it leaves out the C compilers from this process.
This should not cause a problem, except that GPC attempts to locate, for example, the C compiler (cc1) in the same location as GPC was installed. This will not necessarily be correct in the case of separate installations of GCC and GPC. Nor should it be necessary to force these two to reside in the same location.
It would seem to me, therefore, that instead of GPC_EXEC_PREFIX and GCC_EXEC_PREFIX being mutually exclusive, GPC should first search using GPC_EXEC_PREFIX (to locate tools from the GPC installation, e.g., gpc1) and, if the needed tool is not found, then search the GCC_EXEC_PREFIX for tools from the GCC installation, e.g., cc1.
As I said in another post, this will not resolve the problem with mismatched compiler versions.
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).
I believe it will, but doesn't this workaround simply fix the existing "improper" implementation of GCC/GPC_EXEC_PREFIX? (I put "improper" in quotes because there may be a good rationale for the existing method that I do not immediately see.)
I don't know if it's a real issue, but if it helps we could just ignore CRs in the specs file.
I believe the situation arises because Cygwin provides user-selected "text" and "binary" mounts for various parts of the emulated Unix directory hierarchy. The mount type defines how Cygwin should handle file reads and writes, i.e., whether files should contain CR-LF or only LF line ends; this is to accommodate file exchange with Windows programs.
The specific problem occurs when "specs" is built in a directory mounted in "text" mode (so the file is generated with CR-LF line ends) but then is copied during the GPC installation process to a directory mounted in "binary" mode. The CR-LF line ends remain in the file (because the file is an exact copy and is not translated when moving between mount types -- "bug" or "feature" is debatable :-), and GPC chokes when it encounters the CRs.
The problem should not occur if only binary mounts are used in Cygwin. Also, it could be solved during GPC installation by copying "specs" in such a way that the source and destination directory mount types are considered.
How would one do that without writing a special installation script for GPC? At the moment of building the binary distribution there is no way of knowing what type of configuration the binaries will be installed in (most probably an arbitrary and unpredictable mixture of text and binary mounts). People installing the precompiled binaries only have to untar a tarball.
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
On 9 Nov 2001, at 20:42, Prof Abimbola Olowofoyeku wrote:
Also, it could be solved during GPC installation by copying "specs" in such a way that the source and destination directory mount types are considered.
How would one do that without writing a special installation script for GPC?
That's true, if it is desired to have "specs" have CR-LF line ends when installed in a text-mount directory and LF line ends when installed in a binary-mount directory. However, if the convenience of manipulating specs as a normal Windows text file isn't needed, then simply ensuring that it has LF line ends will work in either situation. Adding a "tr -d '\r' ..." to the GPC makefile after the specs file creation should do it.
-- Dave
J. David Bryan wrote:
On 9 Nov 2001, at 20:42, Prof Abimbola Olowofoyeku wrote:
Also, it could be solved during GPC installation by copying "specs" in such a way that the source and destination directory mount types are considered.
How would one do that without writing a special installation script for GPC?
That's true, if it is desired to have "specs" have CR-LF line ends when installed in a text-mount directory and LF line ends when installed in a binary-mount directory. However, if the convenience of manipulating specs as a normal Windows text file isn't needed, then simply ensuring that it has LF line ends will work in either situation. Adding a "tr -d '\r' ..." to the GPC makefile after the specs file creation should do it.
I think it's simpler to do the translation when reading it (and safer, in case the users copies the file around manually or something). That's what my patch (last time) does. So, shouldn't we just use this patch and close this part of the debate? ;-)
I believe that it's only a problem for Cygwin, and then only a problem if the particular directories involved are mounted in different modes, but I'll investigate this a little more and report back later.
I think there's at least a possibility for it to occur on other Dos-based systems (though I've never had this problem under DJGPP so far).
Frank
On 10 Nov 2001, at 5:34, Frank Heckenbach wrote:
So, shouldn't we just use this patch and close this part of the debate?
On 10 Nov 2001, at 5:42, Frank Heckenbach wrote:
The more we change in the driver, the harder integration will become.
Frank, you seem to be arguing that we should patch the driver, but that patching the driver isn't a good idea! ;-)
Regardless, I don't believe it matters whether we patch the driver or make sure that "specs" is generated without CRs.
-- Dave
J. David Bryan wrote:
On 10 Nov 2001, at 5:34, Frank Heckenbach wrote:
So, shouldn't we just use this patch and close this part of the debate?
On 10 Nov 2001, at 5:42, Frank Heckenbach wrote:
The more we change in the driver, the harder integration will become.
Frank, you seem to be arguing that we should patch the driver, but that patching the driver isn't a good idea! ;-)
You got me there. However, this patch is quite minor and (I hope) shouldn't break anthing because there are regularly no CRs in specs. While messing witht he environment variables would significantly change the behaviour in the driver (in an area that was apparently also well considered by the GCC people).
Besides, I *did* suggest to submit this patch to the GCC people. I jsut don't see why I should do that since the patch is not really for my own use.
Regardless, I don't believe it matters whether we patch the driver or make sure that "specs" is generated without CRs.
As far as I understood the Chief that's quite hard if not impossible to make sure in all situations.
Frank
Prof Abimbola Olowofoyeku wrote:
On 9 Nov 01, at 12:20, J. David Bryan wrote:
On 9 Nov 2001, at 4:52, Frank Heckenbach wrote:
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)....
I will investigate more thoroughly over the weekend, but as far as I can see, the "problem" is that GPC is being installed only with a partial set of tools (e.g., no C compiler) and is depending on a prior installation of GCC for the missing parts.
As far as I understand, this is the expected thing. IIRC "make pascal.bindist" is what creates the binary distribution, and it leaves out the C compilers from this process.
Yes. I've been wondering if we should include them. But there's a big problem: If the installed GCC version is the same, then unpacking a GPC binary will overwrite the existing C compiler! I suppose a number of people wouldn't especially welcome that (even though the new one should be just as workable, but it being one of the essential system components, I wouldn't like to have it overwritten on my system without my consent either).
Frank
J. David Bryan wrote:
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).
I believe it will, but doesn't this workaround simply fix the existing "improper" implementation of GCC/GPC_EXEC_PREFIX? (I put "improper" in quotes because there may be a good rationale for the existing method that I do not immediately see.)
The proper things to do, as far the "GCC philosophy" is concerned, is to install the matching GCC version. Period.
We don't do this with pascal.install for reasons explained in another mail, but you're free to do a full install, including C compiler (shouldn't be a problem if two C compiler versions are installed in parallel) or whatever you like.
All of copying/linking the missing files, setting any environment variables, or using special options is "fixing a broken installation".
Frank
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. 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). 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.
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? Is it broken if I install a cross-compiler and therefore need to use the "-b" option? 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?
(Well, *I* certainly don't think so! :-)
-- Dave
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
On 10 Nov 2001, at 8:53, Prof Abimbola Olowofoyeku wrote:
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").
All that just to avoid setting GPC_EXEC_PREFIX? And having to repeat it each time Cygnus bumps the dash number? No thanks, I believe that I prefer my "broken" installation! :-)
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.
Sorry, I was speaking here of native Windows (Mingw).
-- Dave
On 10 Nov 01, at 4:15, J. David Bryan wrote:
On 10 Nov 2001, at 8:53, Prof Abimbola Olowofoyeku wrote:
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").
All that just to avoid setting GPC_EXEC_PREFIX?
Some people like to do things the hard way ;-). Actually, the whole process only takes a few seconds - and it can be done via a script or trivial program.
And having to repeat it each time Cygnus bumps the dash number?
Well, you also have to change your GPC_EXEC_PREFIX in such as case - and it take no longer to do the above.
No thanks, I believe that I prefer my "broken" installation! :-)
Each to his own ;)
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.
Sorry, I was speaking here of native Windows (Mingw).
I see. But suppose everything gets ported to Mingw? It is not impossible to port XFree86 or KDE or anything like that to native Windows.
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
On 10 Nov 2001, at 16:34, Prof Abimbola Olowofoyeku wrote:
But suppose everything gets ported to Mingw? It is not impossible to port XFree86 or KDE or anything like that to native Windows.
Well, we're getting a bit far afield from GPC, but personally I regard programs that *force* me to use specific directory structures of their choosing as "broken." I believe that programs should accommodate me, rather than the other way around.
-- Dave
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. 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). 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.
Or you could try to apply the patches yourself. However, if GPC builds without the patches, also GCC does, since a GPC build includes an (almost) complete GCC build.
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? Is it broken if I install a cross-compiler and therefore need to use the "-b" option?
No, I don't mean `-b' and `-V'. They have a specific purpose, and as I said in another mail, I don't think they'll help here since they'll change the single "preferred" directory for GPC to search things.
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?
You don't. Just set prefix in the configure correspondingly:
Prof Abimbola Olowofoyeku wrote:
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.
Not at all. I've installed many GPCs in my home directories on Solaris, AIX and IRIX systems lately (and probably OSF next week :-). All configured with --prefix=$HOME/usr and no further problems with the dirs.
To sum up things up to here:
You want a way by setting an environment variable. I said there's a way by setting two variables -- if there's any problem with it, please say so (or if you did, I must have missed it in the flood) ...
Various other, more involved, ways like patching things and using scripts, have been discussed which seem like overkill to me.
The root of the problem seems to be the use of a patched GCC and a non-GCC-patched GPC (without installing the non-patched GCC in parallel). This is a "broken" GPC installation.
You can avoid this (don't use the patched GCC, install two GCCs, try to install a GCC-patched GPC, ...), or you can use the environment variables provided for such "broken" installations ...
So ... what's the problem, anyway?
Frank
On 10 Nov 01, at 19:03, Frank Heckenbach wrote:
[...]
Prof Abimbola Olowofoyeku wrote:
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.
Not at all. I've installed many GPCs in my home directories on Solaris, AIX and IRIX systems lately (and probably OSF next week :-). All configured with --prefix=$HOME/usr and no further problems with the dirs.
That is exactly what I was referring to. The question was, why did the gcc people allow environment variables to change the default search paths.
[...]
The root of the problem seems to be the use of a patched GCC and a non-GCC-patched GPC (without installing the non-patched GCC in parallel). This is a "broken" GPC installation.
Yes.
You can avoid this (don't use the patched GCC, install two GCCs, try to install a GCC-patched GPC, ...), or you can use the environment variables provided for such "broken" installations ...
Yes.
So ... what's the problem, anyway?
IIRC, David's problem/query was: why should a gpc distro based on a certain gcc version require the same version of gcc? and, if it does require it, then that does not "seem reasonable".
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
Prof Abimbola Olowofoyeku wrote:
On 10 Nov 01, at 19:03, Frank Heckenbach wrote:
Not at all. I've installed many GPCs in my home directories on Solaris, AIX and IRIX systems lately (and probably OSF next week :-). All configured with --prefix=$HOME/usr and no further problems with the dirs.
That is exactly what I was referring to. The question was, why did the gcc people allow environment variables to change the default search paths.
I can only guess. Perhaps it was added later to make it easier to use precompiled binaries in other directories because not everyone might like to build GCC themselves.
So ... what's the problem, anyway?
IIRC, David's problem/query was: why should a gpc distro based on a certain gcc version require the same version of gcc? and, if it does require it, then that does not "seem reasonable".
As I explained, from the "GCC viewpoint" it does seem reasonable. I suppose if cc1, cpp0 had been installed with GPC by default, no-one would have noticed such a problem at all. So, should I just add additional make targets, say pascal.install-with-gcc and pascal.bindist-with-gcc so those who want can install them without overwriting the (possibly existing) gcc driver? (Of course, this would overwrite cc1, cpp0 if in fact a matching GCC version was installed before.)
Frank
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, just to have, e.g., "collect2" in the right places. That does not seem reasonable.
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.
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.
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.
-- Dave
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
On 9 Nov 01, at 20:36, Prof Abimbola Olowofoyeku wrote:
[...]
Assuming the installed gcc version is 2.95.3 - this then means "..../gcc-lib/i686-pc-cygwin/2.95.3-2/"
Ahem. Here I meant "Assuming the installed gcc version is 2.95.3-2".
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
On 9 Nov 2001, at 20:36, Prof Abimbola Olowofoyeku wrote:
On 9 Nov 01, at 12:35, J. David Bryan wrote:
just to have, e.g., "collect2" in the right places.
Not just for collect2.
N.b.: "e.g." ;-)
That does not seem reasonable.
Reasonable or not, that is the way it is.
Why should that be a requirement? Why would it matter, for example, that the 2.95.3 version of the C compiler is called when the 2.8.1-based version of GPC needs to compile a C program? Or that the 2.95.3 version of collect2 is called to link files generated by a 2.95.2 version of GPC?
What version dependencies exist?
-- Dave
On 9 Nov 01, at 18:06, J. David Bryan wrote:
On 9 Nov 2001, at 20:36, Prof Abimbola Olowofoyeku wrote:
On 9 Nov 01, at 12:35, J. David Bryan wrote:
just to have, e.g., "collect2" in the right places.
Not just for collect2.
N.b.: "e.g." ;-)
e.g., everything else (cpp0, cc1, libgcc.a, etc.).
That does not seem reasonable.
Reasonable or not, that is the way it is.
Why should that be a requirement? Why would it matter, for example, that the 2.95.3 version of the C compiler is called when the 2.8.1-based version of GPC needs to compile a C program? Or that the 2.95.3 version of collect2 is called to link files generated by a 2.95.2 version of GPC?
It would matter because the target machine and target version are hard coded into the driver program, and the driver program uses the target version as the basis for locating the C program files. I think I explained this in my last two posts. Why this should be so is not the issue. It seems that it is so, and has been so for a long time. I am not sure that the gcc guys will change gcc in this respect just to accommodate our special needs here.
So, ISTM that, if gpc is to be merged with gcc eventually, that behaviour will have to remain (Frank or Peter can tell whether this is correct or not). If gpc will engage in "non standard" behaviour (by looking for files elsewhere) then it seems that the gpc driver program needs to be patched with something *additional* to the normal gcc behaviour (as opposed to replacing the normal gcc behaviour). That is why I asked whether we could add an environment variable to do this. It may well be that the "COMPILER_PATH" variable that Frank referred to already does this - but I haven't checked this yet.
What version dependencies exist?
Type "gpc -print-search-dirs" and you will see where it looks for its gcc executables. It is exactly the same place as gcc (try "gcc -print- search-dirs"). You will see that the hard coded paths contain the target compiler version also hard coded.
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
On 9 Nov 2001, at 23:52, Prof Abimbola Olowofoyeku wrote:
It would matter because the target machine and target version are hard coded into the driver program, and the driver program uses the target version as the basis for locating the C program files. I think I explained this in my last two posts.
I'm afraid that you miss my point. There is no *requirement* to place the files where the driver program expects them. Adding the actual location to the path, for example, will work around this. So will employing GCC_EXEC_PATH or COMPILER_PATH.
What I thought you were asserting was that there was some fundamental requirement that (for example) GPC based on gcc-2.95.3 would only work properly if gcc-2.95.3 was also installed due to some inherent dependencies in the tools themselves and not merely due to where they are located. As far as I understand, there are no such dependencies. Yes, by default, the gpc and gcc driver programs will look in certain standard places for their tools, but existing methods are available that will allow the drivers to look elsewhere. Installing a full copy of a specific version of gcc *simply* to satisfy the defaults of the driver program is what I was stating was unnecessary.
As an example, my Windows system is set up with this directory structure:
E:\Programming\GNU --> gcc.exe, ld.exe, etc.
E:\Programming\GNU\mingw32\2.95.3-6 --> cc1.exe, cpp0.exe, etc.
E:\Programming\Pascal --> gpc.exe
E:\Programming\Pascal\i486-pc-mingw32msvc\2.95.3 --> gpc1.exe, etc.
With:
COMPILER_PATH=E:\Programming\GNU\mingw32\2.95.3-6 GPC_EXEC_PREFIX=E:\Programming\Pascal\
...I can compile and link C and Pascal programs with GPC with no trouble.
Chief, I believe that we're arguing two different points here. :-)
-- Dave
J. David Bryan wrote:
What I thought you were asserting was that there was some fundamental requirement that (for example) GPC based on gcc-2.95.3 would only work properly if gcc-2.95.3 was also installed due to some inherent dependencies in the tools themselves and not merely due to where they are located. As far as I understand, there are no such dependencies.
As far as I know, it's not guaranteed that there are no such dependencies. E.g., things in libgcc.a might change. This can also depend on the platform (e.g., on Linux there seem to be few such problems, at least unless pre-ELF files are involved ;-). I've heard that C++ is more sensible to such issues (e.g., the recent DJGPP announcement said: "Also please DON'T mix C++ libraries (or object files) built with different compiler versions. C++ sources should be recompiled (seems that there is no need to do this for C sources).").
But then, I've done a joint Pascal/C++ project some years ago, using a GPC based on 2.8.1 and a g++ version of egcs-2.91.whatever, and a GMP library compiled by whatever C compiler (maybe not even gcc, but the system compiler), and all that on Solaris, and it worked ...
Frank
On 10 Nov 2001, at 5:55, Frank Heckenbach wrote:
As far as I know, it's not guaranteed that there are no such dependencies. E.g., things in libgcc.a might change.
I confess that I know rather little about GCC internals, but any given gcc- compiled object file might depend on routines contained in the libgcc.a file that comes with GCC (i.e., when compiling, GCC may implicitly emit calls to routines in libgcc.a to support certain source constructs), correct? If so, then it seems to me that *every* object file that will be linked in a given executable might possibly be dependent on the particular version of GCC that was used to compile it (because it will be dependent on a particular version of libgcc.a -- the version associated with the compiler used to produce the object file).
The only guaranteed configuration, then, would be to ensure that everything -- every compiled source file, every third-party library routine, every run- time library component -- that will be linked together had been compiled with the identical version of GCC (so that they would all be dependent on the same version of libgcc.a).
I accept what you say, but how is that ever accomplished in practice?
But then, I've done a joint Pascal/C++ project some years ago, using a GPC based on 2.8.1 and a g++ version of egcs-2.91.whatever, and a GMP library compiled by whatever C compiler (maybe not even gcc, but the system compiler), and all that on Solaris, and it worked ...
Or is it? ;-)
-- Dave
On 10 Nov 01, at 1:31, J. David Bryan wrote:
[...]
The only guaranteed configuration, then, would be to ensure that everything -- every compiled source file, every third-party library routine, every run- time library component -- that will be linked together had been compiled with the identical version of GCC (so that they would all be dependent on the same version of libgcc.a).
Yes, that is the only "guaranteed" configuration. In the vast majority of cases, object files should be compatible across gcc versions (except perhaps with the infamous gcc-2.96), and programmers should avoid doing anything which would violate compatibility. But this doesn't mean that they always do.
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
J. David Bryan wrote:
On 10 Nov 2001, at 5:55, Frank Heckenbach wrote:
As far as I know, it's not guaranteed that there are no such dependencies. E.g., things in libgcc.a might change.
I confess that I know rather little about GCC internals, but any given gcc- compiled object file might depend on routines contained in the libgcc.a file that comes with GCC (i.e., when compiling, GCC may implicitly emit calls to routines in libgcc.a to support certain source constructs), correct?
Yes.
If so, then it seems to me that *every* object file that will be linked in a given executable might possibly be dependent on the particular version of GCC that was used to compile it (because it will be dependent on a particular version of libgcc.a -- the version associated with the compiler used to produce the object file).
The only guaranteed configuration, then, would be to ensure that everything -- every compiled source file, every third-party library routine, every run- time library component -- that will be linked together had been compiled with the identical version of GCC (so that they would all be dependent on the same version of libgcc.a).
Yes (and I thought this was the original question in this sub-thread).
I accept what you say, but how is that ever accomplished in practice?
By recompiling everything, to be sure (see the quote from the DJGPP announcement).
I don't think "normal" people will upgrade their compiler version that often (as for GPC, it means the backend version, not the GPC frontend version), and for, say, a Linux distribution, I do expect them to recompile everything when they start using a new GCC version.
But then, I've done a joint Pascal/C++ project some years ago, using a GPC based on 2.8.1 and a g++ version of egcs-2.91.whatever, and a GMP library compiled by whatever C compiler (maybe not even gcc, but the system compiler), and all that on Solaris, and it worked ...
Or is it? ;-)
As long as it's for our own use, we can inverstigate any problems arising from it. If we had shipped the result to an important customer, we might have done things a little differently ... ;-)
Frank
Let's see if we can consolidate some of these threads....
On 10 Nov 2001, at 18:53, Frank Heckenbach wrote:
...(and I thought this was the original question in this sub-thread).
I confess that I've completely lost track of the original question!
On 10 Nov 2001, at 18:56, Frank Heckenbach wrote:
As far as I understood the Chief that's quite hard if not impossible to make sure in all situations.
I'm not sure I understand why "tr -d '\r' ..." won't work in all situations (it certainly works for Cygwin), but, as I noted earlier, I don't believe that doing this is any better or worse than patching gpc.c.
On 10 Nov 2001, at 19:03, Frank Heckenbach wrote:
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?
You don't. Just set prefix in the configure correspondingly:
Hmmm...I have always considered the introduction of run-time variables, as opposed to changing values that are hard-coded in the program, to be a significant advance in the history of computation. ;-)
You want a way by setting an environment variable.
Actually, the original point of argument (I think!) was that Cygwin provided a gcc-2.95.3-x, GPC provided a gpc-2.95.3, and to reconcile the difference, was it better to (a) copy all of the GCC files to the GPC directories, (b) patch and recompile GPC to accommodate the Cygwin numbering scheme, or (c) set GCC_EXEC_PREFIX to point at the GCC installation. The "correct" answer seems to be, "Whichever method you prefer!"
So ... what's the problem, anyway?
Too much time on our hands? ;-)
On 10 Nov 2001, at 21:24, Frank Heckenbach wrote:
As I explained, from the "GCC viewpoint" it does seem reasonable. I suppose if cc1, cpp0 had been installed with GPC by default, no-one would have noticed such a problem at all.
But it isn't just a problem of matching tools, is it? Wouldn't everything, as you say, have to match the compiler version? Wouldn't the C library that will ultimately be linked in, for example, have to be compiled with the same GCC version to be guaranteed compatible? We can't install a GPC (and cc1, etc.) based on gcc-2.95.3 on a system that contains a C library compiled by gcc-2.95.2, can we?
If I understand your point about GCC versions correctly, then *everything* that will be bound in to a given executable must be compiled with the same GCC version. We can't guarantee that unless we supply everything that might be bound in to a given program, so we would have to include both the C library and the Pascal library (because even "pure Pascal" programs are going to pull routines from the C library).
-- Dave
J. David Bryan wrote:
On 10 Nov 2001, at 19:03, Frank Heckenbach wrote:
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?
You don't. Just set prefix in the configure correspondingly:
Hmmm...I have always considered the introduction of run-time variables, as opposed to changing values that are hard-coded in the program, to be a significant advance in the history of computation. ;-)
What do you want??? GPC has BOTH a configure prefix AND an environment variable.
If you're missing such a variable in any other program, ask THEIR respective authors.
If you want a global prefix for ALL programs, that's chroot. (Oh, Windows doesn't have it? Ask Microsoft then.)
You want a way by setting an environment variable.
Actually, the original point of argument (I think!) was that Cygwin provided a gcc-2.95.3-x, GPC provided a gpc-2.95.3, and to reconcile the difference, was it better to (a) copy all of the GCC files to the GPC directories, (b) patch and recompile GPC to accommodate the Cygwin numbering scheme, or (c) set GCC_EXEC_PREFIX to point at the GCC installation. The "correct" answer seems to be, "Whichever method you prefer!"
As I said a number of times now the most correct answer seems to be NEITHER of these, but to install cc1 and cpp0 with GPC, and the next best one to set COMPILER_PATH and LIBRARY_PATH (and YOU have confirmed that it works for you). (Though I must admit that I've suggested (a) in other threads before I found out about them recently.)
So ... what's the problem, anyway?
Too much time on our hands? ;-)
Not on mine, sorry. So I quit this thread now. If there's anything (new!) that I should read, please change the subject line.
Frank
Prof Abimbola Olowofoyeku wrote:
It would matter because the target machine and target version are hard coded into the driver program, and the driver program uses the target version as the basis for locating the C program files. I think I explained this in my last two posts. Why this should be so is not the issue. It seems that it is so, and has been so for a long time.
Not really hard-coded. They can be overwritten with `-b' and `-V', respectively. But I don't think that's the way to go here.
So, ISTM that, if gpc is to be merged with gcc eventually, that behaviour will have to remain (Frank or Peter can tell whether this is correct or not). If gpc will engage in "non standard" behaviour (by looking for files elsewhere) then it seems that the gpc driver program needs to be patched with something *additional* to the normal gcc behaviour (as opposed to replacing the normal gcc behaviour). That is why I asked whether we could add an environment variable to do this.
In fact, that's an issue. The more we change in the driver, the harder integration will become. So, provided `COMPILER_PATH' and `LINKER_PATH' will work, I don't feel like adding any other ways. It's not that much of a difference having to set one or two environment variables.
Frank
On 9 Nov 2001, at 20:36, Prof Abimbola Olowofoyeku wrote:
That functionality is already present with GCC_EXEC_PREFIX.
As far as I understand, it isn't - or maybe my understanding is just wrong.
[...]
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".
Actually, it tries the GCC_EXEC_PREFIX both with and without the machine and version number. Try setting GCC_EXEC_PREFIX to "/aaa/bbb/" for example, and then do:
gcc -print-search-dirs
You'll note that the "programs" and "libraries" searches are done first with "/aaa/bbb/i686-pc-cygwin/2.95.2/" and then with "/aaa/bbb/" (among other variations).
So setting GCC_EXEC_PREFIX to:
"..../gcc-lib/i686-pc-cygwin/2.95.3-2/"
will try "..../gcc-lib/i686-pc-cygwin/2.95.3-2/i686-pc-cygwin/2.95.2/", which will fail, and then will try "..../gcc-lib/i686-pc-cygwin/2.95.3-2/", which will succeed.
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?
Specs is built essentially by doing:
gpc -dumpspecs > specs
or
gcc -dumpspecs > specs
If GPC and GCC have different internal specs and specs processing, then they are not interchangeable.
-- Dave
-
Andris Pavenis -
Frank Heckenbach -
J. David Bryan -
Pierre Muller -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)