On 18 Sep 2002 at 9:21, I wrote:
On 18 Sep 2002 at 0:57, Frank Heckenbach wrote:
[...]
But something else (I still don't really understand the story): Searching of gpcpp does not use the unit-path. The path is hard-coded while building GPC, so if it is installed in the same directory, no option is needed to find it. Otherwise it can be set with a `-B' option or an environment variable GPC_EXEC_PREFIX. Is that what the IDE sets for the "bin directory"?
This is an example of output of the "compile log" window: "c:\dev_gpc\bin\gpc --automake c:\dev_gpc\examples\untitled1.pas -oc:\dev_gpc\examples\untitled1.exe -fno-inline -fno-io-checking -fno-stack-checking -O1 -march=i386 -mcpu=i386 -funit-path=c:\dev_gpc\units -Bc:\dev_gpc\lib\ -Bc:\dev_gpc\lib\gcc- lib\ -Bc:\dev_gpc\bin"
So the necessary "-B" switches are there - and I cannot see why there should be a problem.
I have now checked the compile log again, and I can see that the entire command line contains about 273 characters. Perhaps we have come across a DOS limitation here? I seem to remember that DOS (or command.com) has some limits in respect of how long a command line can be (128 characters?). If this is the problem, then I don't know what one can do about it.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 18 Sep 2002 at 9:21, I wrote:
On 18 Sep 2002 at 0:57, Frank Heckenbach wrote:
[...]
But something else (I still don't really understand the story): Searching of gpcpp does not use the unit-path. The path is hard-coded while building GPC, so if it is installed in the same directory, no option is needed to find it. Otherwise it can be set with a `-B' option or an environment variable GPC_EXEC_PREFIX. Is that what the IDE sets for the "bin directory"?
This is an example of output of the "compile log" window: "c:\dev_gpc\bin\gpc --automake c:\dev_gpc\examples\untitled1.pas -oc:\dev_gpc\examples\untitled1.exe -fno-inline -fno-io-checking -fno-stack-checking -O1 -march=i386 -mcpu=i386 -funit-path=c:\dev_gpc\units -Bc:\dev_gpc\lib\ -Bc:\dev_gpc\lib\gcc- lib\ -Bc:\dev_gpc\bin"
So the necessary "-B" switches are there - and I cannot see why there should be a problem.
I have now checked the compile log again, and I can see that the entire command line contains about 273 characters. Perhaps we have come across a DOS limitation here? I seem to remember that DOS (or command.com) has some limits in respect of how long a command line can be (128 characters?). If this is the problem, then I don't know what one can do about it.
I don't suppose it's that, since Maurice said that omitting the `c:' helps. That certainly doesn't bring the length below 128. ;-)
I know that DJGPP uses some ways around this limit when one DJGPP program calls another one. I don't know if/what mingw does, or if the limit exists at all under Windows. Someone might want to try it, but I guess if the limit really applied, this would have been noticed much earlier.
Frank
On 19 Sep 2002 at 1:18, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
[...]
I have now checked the compile log again, and I can see that the entire command line contains about 273 characters. Perhaps we have come across a DOS limitation here? I seem to remember that DOS (or command.com) has some limits in respect of how long a command line can be (128 characters?). If this is the problem, then I don't know what one can do about it.
I don't suppose it's that, since Maurice said that omitting the `c:' helps. That certainly doesn't bring the length below 128. ;-)
No, this was a red herring.
I know that DJGPP uses some ways around this limit when one DJGPP program calls another one. I don't know if/what mingw does, or if the limit exists at all under Windows. Someone might want to try it, but I guess if the limit really applied, this would have been noticed much earlier.
Correct. The problem is with front slashes (or so it seems).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku a écrit:
On 19 Sep 2002 at 1:18, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
[...]
I know that DJGPP uses some ways around this limit when one DJGPP program calls another one. I don't know if/what mingw does, or if the limit exists at all under Windows. Someone might want to try it, but I guess if the limit really applied, this would have been noticed much earlier.
Correct. The problem is with front slashes (or so it seems).
This is probably not the problem
I have tried the same four checks with front slashes after the -B (no front slashes possibles in the call c:\mingw\bin\gpc, command.com will not find the program) The results are exactly the sames.
I have also tried with djgpp, simply replacing everywhere mingw by djgpp (all is in a clean dos box with only path=c:\windows;c:\windows\command to avoid finding the wrong compiler) The four test work then, both with front and bacward slashes, only with the warning gpc.exe: file path prefix `c:/djgpp/bin' never used when omitting the trailing / or \
Maurice
On 19 Sep 2002 at 11:23, Maurice Lombardi wrote:
Prof Abimbola Olowofoyeku a écrit:
[...]
Correct. The problem is with front slashes (or so it seems).
This is probably not the problem
It is the problem. See below.
I have tried the same four checks with front slashes after the -B (no front slashes possibles in the call c:\mingw\bin\gpc, command.com will not find the program)
This is precisely the problem. Whatever you pass to gpc, the gpc driver internally changes back slashes to front slashes when it wants to spawn its subprocesses (in the first instance, gpcpp). This is then treated as an invalid command by command.com, and the gpc driver dies with a complaint that it cannot find gpcpp (actually, it just cannot execute it). This problem only exists under Win9x.
So the solution seems to be not to change the back slashes to front slashes when running under Mingw - which is unfortunate, because Win NT/2000/XP do not mind the front slashes.
The attached diff seems to solve the problem. I can release a patched version of gpc.exe if it is deemed that the patch is appropriate for inclusion in GPC (I hope also that the C code is correct!).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
*** gpc.c.original Thu May 09 18:43:54 2002 --- gpc.c Thu Sep 19 11:11:20 2002 *************** find_a_file (pprefix, name, mode) *** 2239,2244 **** --- 2239,2245 ---- int mode; { char *temp; + int i; const char *file_suffix = ((mode & X_OK) != 0 ? EXECUTABLE_SUFFIX : ""); struct prefix_list *pl; int len = pprefix->max_len + strlen (name) + strlen (file_suffix) + 1; *************** find_a_file (pprefix, name, mode) *** 2294,2299 **** --- 2295,2303 ---- strcat (temp, machine_suffix); strcat (temp, name); strcat (temp, file_suffix); + #if defined(GPC) && defined(__MINGW32__) /* problems with front slashes under Win9x */ + for (i = 0; i <= strlen (temp); i++) if (temp[i] == '/') temp[i] = '\'; + #endif /* GPC && __MINGW32__ */ if (access (temp, mode) == 0) { if (pl->used_flag_ptr != 0) *************** find_a_file (pprefix, name, mode) *** 2306,2311 **** --- 2310,2318 ---- strcpy (temp, pl->prefix); strcat (temp, machine_suffix); strcat (temp, name); + #if defined(GPC) && defined(__MINGW32__) /* problems with front slashes under Win9x */ + for (i = 0; i <= strlen (temp); i++) if (temp[i] == '/') temp[i] = '\'; + #endif /* GPC && __MINGW32__ */ if (access (temp, mode) == 0) { if (pl->used_flag_ptr != 0) *************** find_a_file (pprefix, name, mode) *** 2326,2331 **** --- 2333,2341 ---- strcat (temp, just_machine_suffix); strcat (temp, name); strcat (temp, file_suffix); + #if defined(GPC) && defined(__MINGW32__) /* problems with front slashes under Win9x */ + for (i = 0; i <= strlen (temp); i++) if (temp[i] == '/') temp[i] = '\'; + #endif /* GPC && __MINGW32__ */ if (access (temp, mode) == 0) { if (pl->used_flag_ptr != 0) *************** find_a_file (pprefix, name, mode) *** 2337,2342 **** --- 2347,2355 ---- strcpy (temp, pl->prefix); strcat (temp, just_machine_suffix); strcat (temp, name); + #if defined(GPC) && defined(__MINGW32__) /* problems with front slashes under Win9x */ + for (i = 0; i <= strlen (temp); i++) if (temp[i] == '/') temp[i] = '\'; + #endif /* GPC && __MINGW32__ */ if (access (temp, mode) == 0) { if (pl->used_flag_ptr != 0) *************** find_a_file (pprefix, name, mode) *** 2356,2361 **** --- 2369,2377 ---- strcpy (temp, pl->prefix); strcat (temp, name); strcat (temp, file_suffix); + #if defined(GPC) && defined(__MINGW32__) /* problems with front slashes under Win9x */ + for (i = 0; i <= strlen (temp); i++) if (temp[i] == '/') temp[i] = '\'; + #endif /* GPC && __MINGW32__ */ if (access (temp, mode) == 0) { if (pl->used_flag_ptr != 0) *************** find_a_file (pprefix, name, mode) *** 2366,2371 **** --- 2382,2390 ----
strcpy (temp, pl->prefix); strcat (temp, name); + #if defined(GPC) && defined(__MINGW32__) /* problems with front slashes under Win9x */ + for (i = 0; i <= strlen (temp); i++) if (temp[i] == '/') temp[i] = '\'; + #endif /* GPC && __MINGW32__ */ if (access (temp, mode) == 0) { if (pl->used_flag_ptr != 0)
Prof Abimbola Olowofoyeku wrote:
Correct. The problem is with front slashes (or so it seems).
This is precisely the problem. Whatever you pass to gpc, the gpc driver internally changes back slashes to front slashes when it wants to spawn its subprocesses (in the first instance, gpcpp). This is then treated as an invalid command by command.com, and the gpc driver dies with a complaint that it cannot find gpcpp (actually, it just cannot execute it). This problem only exists under Win9x.
So the solution seems to be not to change the back slashes to front slashes when running under Mingw - which is unfortunate, because Win NT/2000/XP do not mind the front slashes.
The attached diff seems to solve the problem. I can release a patched version of gpc.exe if it is deemed that the patch is appropriate for inclusion in GPC (I hope also that the C code is correct!).
The code looks correct (though a C wizard would do it differently ;-). However, I'm not sure if converting forth and back it so good.
Did you find the place where it changes back slashes to front slashes? I suppose it's the places where something is set to DIR_SEPARATOR in gpc.c. However, config/i386/xm-mingw32.h says:
#define DIR_SEPARATOR '\' #define DIR_SEPARATOR_2 '/'
So I still don't understand it. DIR_SEPARATOR should be correct (unlike DIR_SEPARATOR_2), while Cygwin has them vice versa (which should also be good).
Anyway, you might want to try changing the assignments (search for ` = DIR_SEPARATOR', and also the declaration of dir_separator_str) to DIR_SEPARATOR_2, without applying your patch.
I don't really see why this should work, but if it does, at least I know what we're at ...
Frank
On 20 Sep 2002 at 6:48, Frank Heckenbach wrote:
Prof Abimbola Olowofoyeku wrote:
[...]
The attached diff seems to solve the problem. I can release a patched version of gpc.exe if it is deemed that the patch is appropriate for inclusion in GPC (I hope also that the C code is correct!).
The code looks correct (though a C wizard would do it differently ;-). However, I'm not sure if converting forth and back it so good.
No, I don't like it either.
Did you find the place where it changes back slashes to front slashes? I suppose it's the places where something is set to DIR_SEPARATOR in gpc.c.
There are so many instances of DIR_SEPARAT* in gpc.c, and quote often, "/" is also checked for in such places. It is difficult to know where exactly the change is taking place.
However, config/i386/xm-mingw32.h says:
#define DIR_SEPARATOR '\' #define DIR_SEPARATOR_2 '/'
Yes, that is correct.
So I still don't understand it. DIR_SEPARATOR should be correct
It is correct, AFAICS.
(unlike DIR_SEPARATOR_2), while Cygwin has them vice versa (which should also be good).
Anyway, you might want to try changing the assignments (search for ` = DIR_SEPARATOR', and also the declaration of dir_separator_str) to DIR_SEPARATOR_2, without applying your patch.
I don't really see why this should work, but if it does, at least I know what we're at ...
That was my first point of call, and nothing I tried there worked. I will have another go over the weekend ....
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
Did you find the place where it changes back slashes to front slashes? I suppose it's the places where something is set to DIR_SEPARATOR in gpc.c.
There are so many instances of DIR_SEPARAT* in gpc.c, and quote often, "/" is also checked for in such places. It is difficult to know where exactly the change is taking place.
I'm changing them to use IS_DIR_SEPARATOR and IS_ABSOLUTE_PATHNAME now (thereby also synching it more with gcc-3.x). I could send you a diff, or you could wait for the next alpha, but I don't see how any of these changes affect the problematic behaviour, actually.
Anyway, you might want to try changing the assignments (search for ` = DIR_SEPARATOR', and also the declaration of dir_separator_str) to DIR_SEPARATOR_2, without applying your patch.
I don't really see why this should work, but if it does, at least I know what we're at ...
That was my first point of call, and nothing I tried there worked. I will have another go over the weekend ....
Please do. If you find where the conversion is taking place, this should help us fix it.
Frank
On 20 Sep 2002 at 6:48, Frank Heckenbach wrote:
[...]
Did you find the place where it changes back slashes to front slashes? I suppose it's the places where something is set to DIR_SEPARATOR in gpc.c. However, config/i386/xm-mingw32.h says:
#define DIR_SEPARATOR '\' #define DIR_SEPARATOR_2 '/'
I have found the problem. The source for the "Mingw special" edition (gcc-2.95.3-6) contains this in config/i386/xm-mingw32.h:
#ifdef TARGET_W9x /* This kludge must go, once we can get '/' to work on W9x */ #define DIR_SEPARATOR_2 '/' #define DIR_SEPARATOR '\' #else #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\' #endif
So, someone has opted not to support Win9x automatically. Murphy's Law has been proven once again - this is where I should have looked first, but it is where I looked last :(
Anyway, the solution is simple now, and I have sorted it out. I have also learnt my lesson (I hope!) - I will always look in the config/i386/ headers from now on ...
In any case, for those who are interested, I have put a patched version of the gpc driver on the GPC ftp site: http://www.gnu-pascal.de/contrib/chief/win32/gpc_fix1.zip
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
On 20 Sep 2002 at 6:48, Frank Heckenbach wrote:
[...]
Did you find the place where it changes back slashes to front slashes? I suppose it's the places where something is set to DIR_SEPARATOR in gpc.c. However, config/i386/xm-mingw32.h says:
#define DIR_SEPARATOR '\' #define DIR_SEPARATOR_2 '/'
I have found the problem. The source for the "Mingw special" edition (gcc-2.95.3-6) contains this in config/i386/xm-mingw32.h:
#ifdef TARGET_W9x /* This kludge must go, once we can get '/' to work on W9x */ #define DIR_SEPARATOR_2 '/' #define DIR_SEPARATOR '\' #else #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\' #endif
So, someone has opted not to support Win9x automatically. Murphy's Law has been proven once again - this is where I should have looked first, but it is where I looked last :(
And I suppose TARGET_W9x was not set when building it.
Well, I see. I had supposed something like this, but couldn't find it (obviously, since I don't have the "special edition").
In any case, for those who are interested, I have put a patched version of the gpc driver on the GPC ftp site: http://www.gnu-pascal.de/contrib/chief/win32/gpc_fix1.zip
This file contains only the exectuable, so I don't know what you changed in the source. Did you just set TARGET_W9x (but then the problem remains for those that build it without doing so), or change anything in gpc.c?
I could easily make gpc.c put a `' if either of the DIR_SEPARATOR's is `'. This will then also include Cygwin where it's not necessary AFAIK, but shouldn't hurt either, I guess.
Frank
On 21 Sep 2002 at 4:48, Frank Heckenbach wrote:
[...]
I have found the problem. The source for the "Mingw special" edition (gcc-2.95.3-6) contains this in config/i386/xm-mingw32.h:
#ifdef TARGET_W9x /* This kludge must go, once we can get '/' to #work on W9x */ #define DIR_SEPARATOR_2 '/' #define DIR_SEPARATOR '\' #else #define DIR_SEPARATOR '/' #define DIR_SEPARATOR_2 '\' #endif
So, someone has opted not to support Win9x automatically. Murphy's Law has been proven once again - this is where I should have looked first, but it is where I looked last :(
And I suppose TARGET_W9x was not set when building it.
No. I didn't even realise that it existed :(
Well, I see. I had supposed something like this, but couldn't find it (obviously, since I don't have the "special edition").
In any case, for those who are interested, I have put a patched version of the gpc driver on the GPC ftp site: http://www.gnu-pascal.de/contrib/chief/win32/gpc_fix1.zip
This file contains only the exectuable, so I don't know what you changed in the source. Did you just set TARGET_W9x (but then the problem remains for those that build it without doing so), or change anything in gpc.c?
Nothing was changed in any file. I just rebuilt gpc.c with "-DTARGET_W9x" as part of the CFLAGS.
I could easily make gpc.c put a `' if either of the DIR_SEPARATOR's is `'. This will then also include Cygwin where it's not necessary AFAIK, but shouldn't hurt either, I guess.
I don't think that this is necessary. The whole problem was just another Windows "gotcha". I have added "-DTARGET_W9x" to the CFLAGS in the script that I use to build GPC for Mingw so that should cover the future. I still intend to keep looking at the config/i386/ files in any new Mingw gcc updates anyway, just to make sure that I am not missing anything ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Maurice Lombardi wrote:
Prof Abimbola Olowofoyeku a écrit:
On 19 Sep 2002 at 1:18, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
[...]
I know that DJGPP uses some ways around this limit when one DJGPP program calls another one. I don't know if/what mingw does, or if the limit exists at all under Windows. Someone might want to try it, but I guess if the limit really applied, this would have been noticed much earlier.
Correct. The problem is with front slashes (or so it seems).
This is probably not the problem
I have tried the same four checks with front slashes after the -B (no front slashes possibles in the call c:\mingw\bin\gpc, command.com will not find the program) The results are exactly the sames.
I have also tried with djgpp, simply replacing everywhere mingw by djgpp (all is in a clean dos box with only path=c:\windows;c:\windows\command to avoid finding the wrong compiler) The four test work then, both with front and bacward slashes, only with the warning gpc.exe: file path prefix `c:/djgpp/bin' never used when omitting the trailing / or \
1. Are you talking about the same thing in the first place? AFAIUI, The Chief's issue is with `-B' options, yours with multiple directories in `--unit-path'. The union of both problems would be multiple dirs in a `-B' option, but AFAIK GPC doesn't allow that at all (though it allows multiple `-B' options, though I really wonder when someone should need them ...)
2. The trailing slash is required for `-B' (also on other systems). That's GCC's behaviour, so I don't want to change it in GPC alone.
3. If you get that warning, that means that GPC didn't need the `-B' because it found things anyway (as it should when installed correctly). Therefore, your other tests might not be very meaningful. You might want to try moving gpcpp.exe to a directory where GPC will not find it automatically.
Frank
On 20 Sep 2002 at 6:09, Frank Heckenbach wrote:
[...]
- Are you talking about the same thing in the first place? AFAIUI, The Chief's issue is with `-B' options, yours with multiple directories in `--unit-path'. The union of both problems would be multiple dirs in a `-B' option, but AFAIK GPC doesn't allow that at all (though it allows multiple `-B' options, though I really wonder when someone should need them ...)
Actually my issue is not with "-B" options. The same problem happens even if you don't use any "-B" - indeed it happens whenever you install into somewhere different from the "prefix" directory (i.e., where you may have to use G*C_EXEC_PREFIX).
[...]
- If you get that warning, that means that GPC didn't need the `-B' because it found things anyway (as it should when installed correctly). Therefore, your other tests might not be very meaningful. You might want to try moving gpcpp.exe to a directory where GPC will not find it automatically.
Yes, that is why I told him that installing into "c:\mingw" will not present a good test result, because the prefix is "/mingw" and therefore in such cases, GPC will find all its files, and no "-B" (or G*C_EXEC_PREFIX) is required.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
On 20 Sep 2002 at 6:09, Frank Heckenbach wrote:
[...]
- Are you talking about the same thing in the first place? AFAIUI, The Chief's issue is with `-B' options, yours with multiple directories in `--unit-path'. The union of both problems would be multiple dirs in a `-B' option, but AFAIK GPC doesn't allow that at all (though it allows multiple `-B' options, though I really wonder when someone should need them ...)
Actually my issue is not with "-B" options. The same problem happens even if you don't use any "-B" - indeed it happens whenever you install into somewhere different from the "prefix" directory (i.e., where you may have to use G*C_EXEC_PREFIX).
Generally, G[PC]C_EXEC_PREFIX should be equivalent to `-B'. But there may be subtle differences (probably unintended). Does it also happen if you use `-B' instead of the variable?
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Prof Abimbola Olowofoyeku a écrit:
I have tried the same four checks with front slashes after the -B (no front slashes possibles in the call c:\mingw\bin\gpc, command.com will not find the program) The results are exactly the sames.
I have also tried with djgpp, simply replacing everywhere mingw by djgpp (all is in a clean dos box with only path=c:\windows;c:\windows\command to avoid finding the wrong compiler) The four test work then, both with front and bacward slashes, only with the warning gpc.exe: file path prefix `c:/djgpp/bin' never used when omitting the trailing / or \
- Are you talking about the same thing in the first place? AFAIUI, The Chief's issue is with `-B' options, yours with multiple directories in `--unit-path'. The union of both problems would be multiple dirs in a `-B' option, but AFAIK GPC doesn't allow that at all (though it allows multiple `-B' options, though I really wonder when someone should need them ...)
It was only the -B options. This was a follow up of the following message which was was not transmitted to the list (always this reply to problem, I have asked to have automatic copy to the list, but not everybody has done it, so I sended a private reply to a private reply)
-------------------------------------------------------------------------------------- This bug is not related to dev_gpc. To check I launch a dos box with only PATH=c:\windows;c:\windows\command and I compile a small program manually with or without the -B's
c:\mingw\bin\gpc test.pas --automake works
c:\mingw\bin\gpc test.pas --automake -B\mingw\bin\ works
c:\mingw\bin\gpc test.pas --automake -Bc:\mingw\bin\ fails with: C:\MINGW\BIN\GPC.EXE: installation problem, cannot exec `c:/mingw/bin/as.exe': No such file or directory
c:\mingw\bin\gpc test.pas --automake -Bc:\mingw\bin (no trailing ) works but with: C:\MINGW\BIN\GPC.EXE: file path prefix `c:/mingw/bin' never used
A small C test program compiled with gcc does not fail in all cases but if I try to compile it with gpc it fails like above. ---------------------------------------------------------------------------------------
The chief is probably right for this forward/backward slashes issue: you notice that the error messages have always forward slashes.
Maurice
-
Frank Heckenbach -
Maurice Lombardi -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)