This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2
Pekka Mustonen a écrit:
This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2
Well, I downloaded this week end in found the same
Pekka Mustonen a écrit:
This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2
I was saying: I downloaded this week end DEV+Gnu Pascal 1.9.2 to try and found the same. I found a work around: in the "compiler option" dialog do not put drive names (c:) to the various directories (bin, pascal units, libraries) Then it works, but I understand nothing. An other issue: in the pascal units files you cannot give multiple directories separated by ; this was valid for fpc, but in gpc it is translated to -funit-files=soso and -funit-files=soso;toto is illegal in gpc you need to repeat -funit-file=soso -funit-file=toto
Maurice
Maurice Lombardi a écrit:
Pekka Mustonen a écrit:
This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2
-funit-files=soso and -funit-files=soso;toto is illegal in gpc you need to repeat -funit-file=soso -funit-file=toto
-funit-path instead ...
Maurice
Maurice Lombardi wrote:
Pekka Mustonen a écrit:
This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2
I was saying: I downloaded this week end DEV+Gnu Pascal 1.9.2 to try and found the same. I found a work around: in the "compiler option" dialog do not put drive names (c:) to the various directories (bin, pascal units, libraries) Then it works, but I understand nothing. An other issue: in the pascal units files you cannot give multiple directories separated by ; this was valid for fpc, but in gpc it is translated to -funit-files=soso and -funit-files=soso;toto is illegal in gpc you need to repeat -funit-file=soso -funit-file=toto
-funit-path instead ...
Both issues seem to be related to the PATH_SEPARATOR. It is set to `:' on Unix (as usual there) but it should be `;' on Dos-like systems as set in gcc/config/i386/xm-{cygwin,djgpp,dos,mingw32,os2,vsta}.h.
In my DJGPP version of GPC `--unit-path=foo;bar' works as expected.
If for some reason, PATH_SEPARATOR is set to `:', you should be able to enter several paths separated by `:', and that's why something like `c:\foo' would be regarded as `c' and `\foo'.
I don't know DEV+Gnu Pascal -- which GPC version and which platform does it use, and do they build GPC in a special way, maybe with changes? Can someone reproduce the problem with a GPC built from the original sources?
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"?
It seems that GPC under DJGPP (at least here) wants `/' in the `-B' option -- but only at the end, so I don't think that's it either ...
Frank
On 18 Sep 2002 at 0:57, Frank Heckenbach wrote:
Maurice Lombardi wrote:
Pekka Mustonen a écrit:
This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2
I was saying: I downloaded this week end DEV+Gnu Pascal 1.9.2 to try and found the same. I found a work around: in the "compiler option" dialog do not put drive names (c:) to the various directories (bin, pascal units, libraries) Then it works, but I understand nothing. An other issue: in the pascal units files you cannot give multiple directories separated by ; this was valid for fpc, but in gpc it is translated to -funit-files=soso and -funit-files=soso;toto is illegal in gpc you need to repeat -funit-file=soso -funit-file=toto
-funit-path instead ...
Both issues seem to be related to the PATH_SEPARATOR. It is set to `:' on Unix (as usual there) but it should be `;' on Dos-like systems as set in gcc/config/i386/xm-{cygwin,djgpp,dos,mingw32,os2,vsta}.h.
The path separator is ';'.
In my DJGPP version of GPC `--unit-path=foo;bar' works as expected.
If for some reason, PATH_SEPARATOR is set to `:', you should be able to enter several paths separated by `:', and that's why something like `c:\foo' would be regarded as `c' and `\foo'.
I don't know DEV+Gnu Pascal -- which GPC version and which platform does it use, and do they build GPC in a special way, maybe with changes? Can someone reproduce the problem with a GPC built from the original sources?
Dev+GNU Pascal is simply a Mingw distro of GPC 2.1, coupled with the opensource DevPascal IDE. I added GPC support to DevPascal and released Dev+GNU Pascal after the port was complete. The GPC in it is a bog standard GPC 2.1 for Mingw - exactly the same as the official Mingw binary release. This problem that is being reported has never occurred on my test systems.
However, my test systems all run NT 4.0, Win2000 and WinXP. In the Mingw users list, there have been reported several "issues" relating to Win98 in particular. I guess that this might be one of them.
There is absolutely no logical reason why this problem should exist. Unfortunately, I do not have Win98 (and even if I did have it, I would not install it on my PCs) and so I cannot even begin to find out what the problem is (obviously there is a "feature" in Win98 that is causing the problem). The DevPascal sources are freely available - so people with Delphi 3.0 or higher and Win98 can try and see whether there is any way to get round it (perhaps detecting Win98 and then invoking some sort of hack to get round Win98's problems).
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.
Perhaps adding "c:\dev_gpc\bin" to the Windows PATH might help.
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:
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.
Perhaps adding "c:\dev_gpc\bin" to the Windows PATH might help.
Maybe the trailing `' is the problem. DJGPP seems to want a `/'.
Anyway, if GPC is properly installed (i.e., in the directories it was built for, e.g. gpcpp in <prefix>/lib/gcc-lib/<target>/<platform>), no `-B' option should be needed at all.
Frank
On 19 Sep 2002 at 2:09, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
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.
Perhaps adding "c:\dev_gpc\bin" to the Windows PATH might help.
Maybe the trailing `' is the problem. DJGPP seems to want a `/'.
As I said in a private email, the front slash seems to be be problem. Windows 9x does not seem to be able to handle front slashes when that is part of a path to a program that you want to execute. NT/2000/XP have no problem, and since all my developing and testing is done on those platforms, this deficiency in Windows 9x escaped me (I should have known that there are always hidden "gotchas" in older versions of Windows ;-| ). I am not sure that there is any way to avoid this problem under Windows 9x other than to avoid the use of front slashes in the gpc driver program when spawning other gpc processes, or to avoid it completely when __MINGW32__ is defined. This just introduces more fiddliness into the gpc driver program, and I am not too happy with this solution - but I can't think of any other ...
Anyway, if GPC is properly installed (i.e., in the directories it was built for, e.g. gpcpp in <prefix>/lib/gcc-lib/<target>/<platform>), no `-B' option should be needed at all.
True. But under Windows people like to install things in their own directory of choice. Perhaps this is a case where the installer should not give a choice and should always install into "\mingw" - but that approach would not be satisfactory.
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:
As I said in a private email, the front slash seems to be be problem. Windows 9x does not seem to be able to handle front slashes when that is part of a path to a program that you want to execute. NT/2000/XP have no problem,
You mean the system itself, or only the libraries of Cygwin and/or Mingw? Does a path with front slashes work in command.com, e.g.?
Frank
On 20 Sep 2002 at 6:50, Frank Heckenbach wrote:
Prof Abimbola Olowofoyeku wrote:
As I said in a private email, the front slash seems to be be problem. Windows 9x does not seem to be able to handle front slashes when that is part of a path to a program that you want to execute. NT/2000/XP have no problem,
You mean the system itself, or only the libraries of Cygwin and/or Mingw?
The system itself. The Cygwin and Mingw libraries don't have a problem with front slashes.
Does a path with front slashes work in command.com, e.g.?
No. And that is the problem. Somehow this problem doesn't trip up WinNT/2000/XP, but it certainly trips up Win9x.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
In my DJGPP version of GPC `--unit-path=foo;bar' works as expected.
OK for DJGPP. The problem for me was rhide. It does not work when calling gpc under rhide. If I call gpc in bare dos, it works, also when using a DJGPP response file (gpc toto.pas @parameters) to overcome the command line length limit of DOS. When calling under bash I need to quote as you writed above because ; is line end under bash. With command.com this is not necessary because there is no line end under DOS. I have tried various quotings under rhide, but found no way: apparently there is some interference with the strategy rhide uses to transmit long command lines in DOS. And I do not know the internals.
Maurice
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
In my DJGPP version of GPC `--unit-path=foo;bar' works as expected.
OK for DJGPP. The problem for me was rhide. It does not work when calling gpc under rhide. If I call gpc in bare dos, it works, also when using a DJGPP response file (gpc toto.pas @parameters) to overcome the command line length limit of DOS. When calling under bash I need to quote as you writed above because ; is line end under bash.
Sure.
With command.com this is not necessary because there is no line end under DOS. I have tried various quotings under rhide, but found no way: apparently there is some interference with the strategy rhide uses to transmit long command lines in DOS. And I do not know the internals.
I only took a quick glance at rhide. It seems to use system() which calls command.com unless SHELL is set to $DJDIR/bin/sh.exe. If you have SHELL set, that might be the problem here (though it's generally better ;-) because bash will probably interpret the `;'. Escaping the `;' with `' might also not work because it might be interpreted as a dir separator. Did you try quoting it with "" or ''? Not sure if it should work ...
If nothing else helps, multiple `--unit-path' options with only one directory each are the last resort.
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I only took a quick glance at rhide. It seems to use system() which calls command.com unless SHELL is set to $DJDIR/bin/sh.exe. If you have SHELL set, that might be the problem here (though it's generally better ;-) because bash will probably interpret the `;'. Escaping the `;' with `' might also not work because it might be interpreted as a dir separator. Did you try quoting it with "" or ''? Not sure if it should work ...
Yes. The problem is that rhide does some preprocessing on the line you enter with Option/Compiler Options before storing it. If I open a second time this dialog the '' or "" have been suppressed. ' is not suppressed but gpc does not understand the remaining line. The solution is do double quote as
'"-funit-path=toto;jojo"'
(or the reverse): only the outer pair is suppressed and gpc understands the remaining !!!
If nothing else helps, multiple `--unit-path' options with only one directory each are the last resort.
This is what I was doing since a long time
Maurice
-
Frank Heckenbach -
Maurice Lombardi -
Pekka Mustonen -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)