On 19 May 2004 at 19:57, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 18 May 2004 at 4:21, Frank Heckenbach wrote:
[....]
The problem, as you can see, is the backspace used in Mingw (in the return value of "--print-file-name=units".
I've only taken care about it for DJGPP so far. Try putting the mingw target description instead of `i386-pc-msdosdjgpp' in line 107 of the Makefile:
ifeq ($(PLATFORM),i386-pc-msdosdjgpp)
Changing it to this: ifeq ($(PLATFORM),mingw32) solves that problem.
OK. Is this the only target description that occurs in mingw?
This is the platform that the Mingw gcc maintainers declare and they have been using it for a while (probably as far back as gcc-2.95.3.x). I believe however that some people who build their own gpc for Mingw use things such as "i486-pc-mingw32". This is not "standard", and I guess they can edit the gp sources themselves, unless there is a way of supporting all the various permutations (i[3456]86-pc-mingw32).
Under Mingw, some programs compile without problem, using gp. With others I get this error:
"gp example1 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch"
Did you try it under MSYS and Cygwin? (Just so I can add all necessary target descriptions to the Makefile next time.)
Seems to work okay under MSYS and Cygwin (I did not need to change anything in the sources). Cygwin seems to be perfect, Msys throws up some complaints ("gpc -print-file-name=units installation problem: cannot get default unit path"), but seems to be okay in the end, in the sense that the compiled program is there, and runs okay. I have attached a tarball containing logs of the output of the three Win32 platforms. I have ascertained that the complaints by the MSYS binary arise because "DirectoryExists (Res)" returns False when it should return true (in "GetUnitPath"). I have been unable to locate the actual body of the DirectoryExists function to ascertain why this is happening.
However, later on, I get this:
"gpc -c -s -O2 -march=i486 -mcpu=i686 -I /src/mingw/gcc-3.2.3-20030504- 1/build/gp-0.54 /src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54\gp- parse.c gpc.exe: d:/src/mingw/gcc-3.2.3-20030504-1/build/gp-0.54gp-parse.c: No such file or directory gpc.exe: no input files make: *** [gp-parse.o] Error 1"
Moving "DIR_SEPARATOR=/" to the line just before: "OBJECTS=gpc.o pipes.o pipesc.o stringutils.o fileutils.o md5.o gp- parse.o gp.o $(VERSION_OBJECTS)"
solves that problem too. But this is of course not a satisfactory solution.
Perhaps it is. I think I was a bit overzealous with DIR_SEPARATOR. Replacing `$(real_srcdir)$(DIR_SEPARATOR)' with `$(real_srcdir)/' in the Makefile (which has the same effect as your resetting DIR_SEPARATOR) seems to work OK for DJGPP.
Seems ok here too (at least, it is not causing any problem).
Please check the attached log files and see if they are helpful. So far.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance.
---- File information ----------- File: gp-055-win32-log.tar.gz Date: 21 May 2004, 16:43 Size: 2473 bytes. Type: Unknown