Maurice Lombardi wrote:
It needs only very minor changes to the sources to work. They are contained in the two attached diffs to apply to gpc-20000707 and gcc-2952 source directories.
- the gpc-20000707.diff corrects for an already reported problem with djgpp where pwd under command.com respond c:\djgpp\ garbling ADD_RTS_PARENT_DIR in make-lang.in
! ADD_RTS_PARENT_DIR = sed -e 's,-B([^/]),-B../../\1,g;s,^([^/][^ ]*),../../\1,'` ! ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:][^ ]*),../../\1,'`
I think this should be:
ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^ :]*),../../\1,'
But I'm wondering what the space is about, anyway (can the name of the compiler ever be a single character?), so I think the following is also ok:
ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:]*),../../\1,'
Another problem is that your change would miss, e.g., `-B.' if it's at the end of the string. I think the easiest way to fix it is where ADD_RTS_PARENT_DIR is used:
# The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`"
I'm changing this in the official sources now.
The gcc patch is Peter's area. However, I'm skeptical about the manifest files since they would have to be updated often. I've written a script mkdjgppgpczip which automatically creates manifest etc. It's included in the script directory. It works for cross-building from Linux, might need adjustments for native DJGPP building (never tried that).
When running the demos I have found
- gpc-in-c.h in the unit directory is not in a standard search directory for C header files, I moved it manually (in the zip) into the %DJGPP%\lib\gcc-lib\djgpp\2.952\include
Peter, can we just install it there by default, or do we need permission from the GCC developers?
- intfiledemo.pas does not work. Cannot rewrite a non assigned file under djgpp
This should work (works for me in DosEmu). Does GetTempFileName return a valid name?
program Foo;
uses GPC;
begin Writeln (GetTempFileName); Writeln (GetTempDirectory); CheckInOutRes end.
Frank
Frank Heckenbach a écrit :
Maurice Lombardi wrote:
The gcc patch is Peter's area. However, I'm skeptical about the manifest files since they would have to be updated often.
I agree. It was painly to do it by hand.
- intfiledemo.pas does not work. Cannot rewrite a non assigned file under djgpp
This should work (works for me in DosEmu). Does GetTempFileName return a valid name?
program Foo;
uses GPC;
begin Writeln (GetTempFileName); Writeln (GetTempDirectory); CheckInOutRes end.
c:\djgpp\tmp\GPaaa13491 c:\djgpp\tmp\
This directory exists. With LFN=y a 10 chars filename should work as expected.
Hope this helps
Maurice
Frank Heckenbach a écrit :
Maurice Lombardi wrote:
! ADD_RTS_PARENT_DIR = sed -e 's,-B([^/]),-B../../\1,g;s,^([^/][^ ]*),../../\1,'` ! ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:][^ ]*),../../\1,'`
I think this should be:
ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^ :]*),../../\1,'
But I'm wondering what the space is about, anyway (can the name of the compiler ever be a single character?), so I think the following is also ok:
ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:]*),../../\1,'
No the [^]* is needed. I have downloaded gpc-20000714 and it fails now.
The relevant part of the output is (with some air interspersed)
cd p/rts && c:/djgpp/bin/make.exe CC="`echo c:/djgpp/gnu/gcc-2.952/build.djg/gcc /xgcc -Bc:/djgpp/gnu/gcc-2.952/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/ -Ic:/djgpp/i586-pc-msdosdjgpp/include' ' | sed -e 's,-B([^/][^:]),-B../../\1, g;s,^([^/][^:]*),../../\1,'`" PC="`echo ./xgpc -B./' ' | sed -e 's,-B([^/][^: ]),-B../../\1,g;s,^([^/][^:]*),../../\1,'`" SHELL="c:/djgpp/bin/bash.exe" CFL AGS="-O2" AR="ar" AR_FLAGS="rc" RANLIB="ranlib" RANLIB_TEST="[ -f ranlib ] || ( [ "i586-pc-msdosdjgpp" = "i586-pc-msdosdjgpp" ] && [ -f /usr/bin/ranlib -o -f /b in/ranlib ] )" RTSFLAGS="" DESTDIR="../.." all
make.exe[2]: Entering directory `c:/djgpp/gnu/gcc-2.952/build.djg/gcc/p/rts'
[snip]
../../c:/djgpp/gnu/gcc-2.952/build.djg/gcc/xgcc -Bc:/djgpp/gnu/gcc-2.952/build.d jg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/ -Ic:/djgpp/i586-pc-msdosdjgpp/include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing -declarations -O2 -DRTS_RELEASE_STRING="'`cat /djgpp/gnu/gcc-2.952/gcc/p/rts/rt s-version`'" /djgpp/gnu/gcc-2.952/gcc/p/rts/rts.c
c:/djgpp/tmp/dj300000: ../../c:/djgpp/gnu/gcc-2.952/build.djg/gcc/xgcc: command not found
whereas my modified make-lang.in gave
cd p/rts && c:/djgpp/bin/make.exe CC="`echo c:/djgpp/gnu/gcc-2.952/build.djg/gcc/xgcc -Bc:/djgpp/gnu/gcc-2.952/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/ -Ic:/djgpp/i586-pc-msdosdjgpp/include | sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:][^ ]*),../../\1,'`" PC="`echo ./xgpc -B./ | sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:][^ ]*),../../\1,'`" SHELL="c:/djgpp/bin/bash.exe" CFLAGS="-O2" AR="ar" AR_FLAGS="rc" RANLIB="ranlib" RANLIB_TEST="[ -f ranlib ] || ( [ "i586-pc-msdosdjgpp" = "i586-pc-msdosdjgpp" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." all
make.exe[2]: Entering directory `c:/djgpp/gnu/gcc-2.952/build.djg/gcc/p/rts'
[snip]
c:/djgpp/gnu/gcc-2.952/build.djg/gcc/xgcc -Bc:/djgpp/gnu/gcc-2.952/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/ -Ic:/djgpp/i586-pc-msdosdjgpp/include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 -DRTS_RELEASE_STRING="'`cat /djgpp/gnu/gcc-2.952/gcc/p/rts/rts-version`'" /djgpp/gnu/gcc-2.952/gcc/p/rts/rts.c
I need a great supply of asprin nearby when trying to decipher those sed scripts
Maurice
Dear Maurice:
I noticed your complex expression:
The relevant part of the output is (with some air interspersed)
cd p/rts && c:/djgpp/bin/make.exe CC="`echo c:/djgpp/gnu/gcc-2.952/build.djg/gcc /xgcc -Bc:/djgpp/gnu/gcc-2.952/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/ -Ic:/djgpp/i586-pc-msdosdjgpp/include' ' | sed -e 's,-B([^/][^:]),-B../../\1, g;s,^([^/][^:]*),../../\1,'`" PC="`echo ./xgpc -B./' ' | sed -e 's,-B([^/][^: ]),-B../../\1,g;s,^([^/][^:]*),../../\1,'`" SHELL="c:/djgpp/bin/bash.exe" CFL AGS="-O2" AR="ar" AR_FLAGS="rc" RANLIB="ranlib" RANLIB_TEST="[ -f ranlib ] || ( [ "i586-pc-msdosdjgpp" = "i586-pc-msdosdjgpp" ] && [ -f /usr/bin/ranlib -o -f /b in/ranlib ] )" RTSFLAGS="" DESTDIR="../.." all
Even with the space it is hard to get through!
So I thought of mentioning a trick I use: the backslash to break the lines into logical units:
cd p/rts && c:/djgpp/bin/make.exe CC="`echo c:/djgpp/gnu/gcc-2.952/build.djg/gcc /xgcc -Bc:/djgpp/gnu/gcc-2.952/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/ -Ic:/djgpp/i586-pc-msdosdjgpp/include' ' |\ cat |\ sed -e 's,-B([^/][^:]),-B../../\1, g;s,^([^/][^:]*),../../\1,'`" PC="`echo ./xgpc -B./' ' |\ cat |\ sed -e 's,-B([^/][^: ]),-B../../\1,g;s,^([^/][^:]*),../../\1,'`" SHELL="c:/djgpp/bin/bash.exe" CFLAGS="-O2" AR="ar" AR_FLAGS="rc" RANLIB="ranlib" RANLIB_TEST="[ -f ranlib ] || ( [ "i586-pc-msdosdjgpp" = "i586-pc-msdosdjgpp" ] && [ -f /usr/bin/ranlib -o -f /b in/ranlib ] )" RTSFLAGS="" DESTDIR="../.." all
Well, that's not much better (yet) but the idea is to do things like this:
cat my.file |\ tr -d 0-9 |\ sort |\ uniq |\ sed -e "s/this/that/g" |\ cat > my.result
The nice thing about this method is that one can easily see the steps, and it is easy to rearrange and modify. (Of course one must not have any spaces after the backslash!)
Regards,
Tom
Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms@ncifcrf.gov permanent email: toms@alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/
Maurice Lombardi a écrit :
Frank Heckenbach a écrit :
Maurice Lombardi wrote:
! ADD_RTS_PARENT_DIR = sed -e 's,-B([^/]),-B../../\1,g;s,^([^/][^ ]*),../../\1,'` ! ADD_RTS_PARENT_DIR = sed -e 's,-B([^/][^:]),-B../../\1,g;s,^([^/][^:][^ ]*),../../\1,'`
I need a great supply of asprin nearby when trying to decipher those sed scripts
Got the asprin. The logics is (extracted from rx.info)
For example, the character `*' is used to indicate that the preceeding element of a regexp may be repeated 0, 1, or more times.
0 is the problem. It does not excludes the case where : is the second character. And IIRC the + which would mean at least 1 is not understood by all sed's (notably the djgpp one whe had sometimes ago when I tried to figure that out. May be a more recent release ...)
Hope this helps
Maurice
Hello, everybody!
Frank Heckenbach wrote:
The gcc patch is Peter's area. [...]
Well, it is not a patch to the normal GCC source but to the "special edition" that comes with DJGPP.
We can include this patch into the GPC source in order to make it easier to compile GPC natively under DJGPP (and document all this in doc/install.texi). However the correct place for this is between the other scripts that come with DJGPP.
Maurice, would you mind to ask at the DJGPP list (where you are already writing:-) for inclusion of your patches into the regular distribution? As far as I see, they are already providing support for multiple languages ...
- gpc-in-c.h in the unit directory is not in a standard search directory for C header files, I moved it manually (in the zip) into the %DJGPP%\lib\gcc-lib\djgpp\2.952\include
Peter, can we just install it there by default, or do we need permission from the GCC developers?
I see no problems to install it there. We are also installing lots of binaries one directory higher.
Peter
Peter Gerwinski a écrit :
Hello, everybody!
Frank Heckenbach wrote:
The gcc patch is Peter's area. [...]
Well, it is not a patch to the normal GCC source but to the "special edition" that comes with DJGPP.
We can include this patch into the GPC source in order to make it easier to compile GPC natively under DJGPP (and document all this in doc/install.texi). However the correct place for this is between the other scripts that come with DJGPP.
Maurice, would you mind to ask at the DJGPP list (where you are already writing:-) for inclusion of your patches into the regular distribution? As far as I see, they are already providing support for multiple languages ...
I have updated the patches, both in attachment and in
ftp://agnes.dida.physik.uni-essen.de/maurice/build_gpc_djgpp.diff
Instruction for use are at the beginning of this file.
besides a correction to a bug in mkdist.sh which eliminated *.inc files, changes are made for easier use:
- update automatically the manifest file with the actual contents of the demos docdemos and units directories
- modify the build.bat (and djbuild1.sh) in order to have a simple way to build only part of the compilers (typing e.g. build pascal c++), whereas the original built the whole bunch. This was mandatory because djgpp cannot execute in one step too long makefiles due to loss of DPMI handles by Windows. They had already split the process in several steps to overcome this problem. Adding one more compiler brings the problem back.
This produces a full three step bootstrap build. There is however a bug in the last version of binutils (2.10), which makes the comparison of stages 2 and 3 to fail. Downgrading to binutils 2.9.5.1 solves the problem. I have checked that the bug to internal files still remains however.
For use by unexperienced users, the blink asking for the gpc patch (blind because all output is redirected to files, making easier afterwards to examine the results) becomes annoying: there seems to be no more any utility to ask to the user if he wants to apply the gpc patch, since the previous application of the patch is detected automatically. Why not skip this question ?
Hope this helps
Maurice
Maurice Lombardi wrote:
For use by unexperienced users, the blink asking for the gpc patch (blind because all output is redirected to files, making easier afterwards to examine the results) becomes annoying: there seems to be no more any utility to ask to the user if he wants to apply the gpc patch, since the previous application of the patch is detected automatically. Why not skip this question ?
What about applying the patch "manually" from `build.bat' such that, when `configure' comes to that point, GCC is already patched?
Peter
Peter Gerwinski a écrit :
Maurice Lombardi wrote:
For use by unexperienced users, the blink asking for the gpc patch (blind because all output is redirected to files, making easier afterwards to examine the results) becomes annoying: there seems to be no more any utility to ask to the user if he wants to apply the gpc patch, since the previous application of the patch is detected automatically. Why not skip this question ?
What about applying the patch "manually" from `build.bat' such that, when `configure' comes to that point, GCC is already patched?
All is possible, but this is supposed to be in a general djgpp distribution of all compilers. This is not the right place where it belongs. This build.bat is already a dirty trick to overcome the lost of DPMI handles problem, which prevents the simple use of the unix procedure.
Hope this helps
Maurice
-
Frank Heckenbach -
Maurice Lombardi -
Peter Gerwinski -
Tom Schneider