Thanks for your reply!
ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2952b.zip
OK. I try to always give under this same link the lastest gpc snapshot I have
compiled, and which give zero error when
running the whole test suite.
I just updated gcc-2.95.3 version of Djgpp. Every other compiler seems to work well (Thanks to Andris).
Can You update this Pascal compiler (gpc2953b.zip) and documentation and inform me (download site), too?
To force a build in pascal you need to replace --automake by --autobuild as
compilation option.
But this is nowhere provided for in rhide (and in particular is not done when
you hit compile/build) because of the
different logics: looking into the makefiles generated by rhide you have provision
for RHIDE_COMPILE_LINK_AUTOMAKE but
not for RHIDE_COMPILE_LINK_AUTOBUILD
I hope they add this --autobuild as a compilation option to next version.
You have probably an older version of rhide. Better upgrade.
My version is Rhide 1.4.7.8 (latest).
PASCAL_TYPE=GPC
OK
RHIDE_LD_PASCAL=gcc
? for me it is gpc
I change it to gcc, because gpc did not works. I "cheat" from Fortran make.
RHIDE_COMPILE_GPC=$(RHIDE_GPC) $(RHIDE_GPC_FLAGS) $(LOCAL_OPT) -c $(SOURCE_NAME)
-o $(OUTFILE) RHIDE_COMPILE_LINK_GPC=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) $(C_EXTRA_FLAGS)
-o $(OUTFILE) $(OBJFILES) $(LIBRARIES) $(RHIDE_LDFLAGS) $(LDFLAGS) $(RHIDE_LIBS)
RHIDE_COMPILE_LINK_PASCAL_AUTOMAKE=$(RHIDE_COMPILE_LINK_$(PASCAL_TYPE))
This is unnecessary since it is identical to the defaults contained in rhide.
What is necessary is:
RHIDE_COMPILE_LINK_GPC_AUTOMAKE=$(RHIDE_LD_PASCAL) $(RHIDE_LIBDIRS) -o $(OUTFILE)
--autobuild $(RHIDE_GPC_FLAGS)
$(SOURCE_NAME) $(LIBRARIES) $(LDFLAGS) $(RHIDE_LDFLAGS) $(RHIDE_LIBS)
I will try this when you send me the new version of GPC.
i.e. suppress options to automake to avoid those stupid warning messages, and
probably replace --automake altogether by
--autobuild. I am not sure that the latest replacement is still necessary. It was sometimes
ago but I have not checked it recently.
It increases compilation time, but it is more secure. An other convenient way is to use a compilation option --unit-destination-path=
(better included automatically in the
default rhide project if you work mainly in pascal) to put all .o .gpi .gpm
files into a given directory, and to delete
manually all the content of this directory when you want a rebuild (easy only
if you work in a windows dos box not to
need to exit from rhide each time you need to do that, or you can have a .bat
file in your path to do that and do it by
exiting temporarilly from rhide by hitting File/Dos shell). Anyhow be carefull that you have to delete all these files each time you upgrade
to a new version of gpc.
I use Rhide in Windows Dos box and it works.
If you know how to delete in environment file told temporary files automatically, tell me!
Hope this helps,
Thank you very much!
Veli Suorsa --- "People must believe to the future to be able to live!" ---------------------------------- J.V.Snellman, 1890.
Oulu, FINLAND Mailto:VJSuorsa@Surfeu.Fi http://members.surfeu.fi/veli.suorsa/ http://www.surfeu.fi
Mr. Veli Suorsa wrote:
Thanks for your reply!
ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2952b.zip
OK. I try to always give under this same link the lastest gpc snapshot I have compiled, and which give zero error when running the whole test suite.
I just updated gcc-2.95.3 version of Djgpp. Every other compiler seems to work well (Thanks to Andris).
Can You update this Pascal compiler (gpc2953b.zip) and documentation and inform me (download site), too?
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
Briefly speaking:
when applying the patch contained in the p/diff directory (I have taken the same diff as for gcc-295 -2951 -2952 which are identical), I get the following messages
C:\djgpp\gnu\gcc-2.953\gcc>patch -p1 < p\diffs\gcc-2.95.3.diff patching file "expr.c" Hunk #1 succeeded at 4505 (offset 75 lines). Hunk #3 succeeded at 4542 (offset 75 lines). patching file "fold-const.c" Hunk #1 succeeded at 1462 (offset 1 line). patching file "stor-layout.c" patching file "tree.c" Hunk #1 succeeded at 5025 (offset 39 lines). Hunk #3 succeeded at 5100 (offset 39 lines). patching file "tree.h" Hunk #1 succeeded at 1631 (offset 1 line). patching file "tree.def"
No hunk fails, so I proceed with a 3 stage bootstrap. Seems OK but when running dostest it crashes midway, after lots of errors the log file is on agnes:
ftp://agnes.dida.physik.uni-essen.de/home/maurice/make.2953.out
It appears that:
all failed programs include units, either by an explicit uses clause in the main, by a --uses= compilator option or even throug $L there are error messages gpc.exe: installation problem, cannot exec `cpp': No such file or directory (ENOENT)
indeed cpp has been renames cpp0 in this release.
I have include in djgpp.env a [cpp0] identical to [cpp] (and kept [cpp] to be sure. No change.
Looking in the changelog I find indeed
2000-12-18 Zack Weinberg zackw@Stanford.EDU:
* Makefile.in: Rename cpp to cpp0, tradcpp to tradcpp0, and xcpp to cpp throughout. (native): Remove unnecessary dependency on cpp. * gcc.c (C specs): Call cpp0 to do preprocessing, not cpp. * ch/lang-specs.h, cp/lang-specs.h, f/lang-specs.h, objc/lang-specs.h: Call cpp0 to do preprocessing, not cpp.
The corresponding change to p/lang-specs.h has not been done of course. Could it be the only change to do ?
I have no more clue.
Has anybody tried to compile gpc with gcc2953 on a linux machine?
I use bnu210 (and have suppressed accordingly the various -mno-bnu210 in djbuild1.sh). djgpp v2.03 in a W98 dos box. I have first installed gcc2953b.zip and compiled with it.
Hope this helps
Maurice
On 26 Mar 2001, at 16:08, Maurice Lombardi wrote:
[...]
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
Well, I can compile hardly anything with your djgpp binaries - here is an example of output from a simple test program that simply contains "uses GPC;" and does nothing else;
"c:/djgpp/lib/gcc-lib/djgpp/2.952/units/gpc.pas:1680: rts-config.inc: No such file or directory (ENOENT) gpc1.exe: c:\djgpp\bin/gpc.exe exited with status 1"
This happens regardless of where "rts-config.inc" is (and I have tried putting it in all the places that are listed in "gpc -print-search- dirs").
This may of course be a broken djgpp installation, but I doubt it, since gcc works okay.
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:
On 26 Mar 2001, at 16:08, Maurice Lombardi wrote:
[...]
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
Well, I can compile hardly anything with your djgpp binaries - here is an example of output from a simple test program that simply contains "uses GPC;" and does nothing else;
"c:/djgpp/lib/gcc-lib/djgpp/2.952/units/gpc.pas:1680: rts-config.inc: No such file or directory (ENOENT) gpc1.exe: c:\djgpp\bin/gpc.exe exited with status 1"
This happens regardless of where "rts-config.inc" is (and I have tried putting it in all the places that are listed in "gpc -print-search- dirs").
This may of course be a broken djgpp installation, but I doubt it, since gcc works okay.
It is. To be sure that there is nothing wrong in the upload to agnes I have deinstalled cleanly (rm -f @manifest\soso.mft) gcc and gpc, reinstalled gcc2952b.zip from simtelnet and gpc2952b.zip freshly downloaded from agnes (at the moment it was the 20010315 snapshot), compiled and run the gpc demo programs and a couple of more complex programs of mine (which use grx24 and the cephes libml library). Everything is okay. If your previous gpc on djgpp was old the first idea is to check: you have gcc2952b you have the sections [gpc] and [gpcpp] in djgpp.env (in particular [gpcpp] was [gpc-cpp] in older gpc versions) I have bnu210. Do you have an older ? In principle this should make no difference with gcc2952. Differences come with 2953 Hope this helps.
Maurice
On 26 Mar 2001, at 20:07, Maurice Lombardi wrote:
Well, I can compile hardly anything with your djgpp binaries - here is an example of output from a simple test program that simply contains "uses GPC;" and does nothing else;
"c:/djgpp/lib/gcc-lib/djgpp/2.952/units/gpc.pas:1680: rts-config.inc: No such file or directory (ENOENT) gpc1.exe: c:\djgpp\bin/gpc.exe exited with status 1"
This happens regardless of where "rts-config.inc" is (and I have tried putting it in all the places that are listed in "gpc -print-search- dirs").
This may of course be a broken djgpp installation, but I doubt it, since gcc works okay.
It is. To be sure that there is nothing wrong in the upload to agnes I have deinstalled cleanly (rm -f @manifest\soso.mft) gcc and gpc, reinstalled gcc2952b.zip from simtelnet and gpc2952b.zip freshly downloaded from agnes (at the moment it was the 20010315 snapshot), compiled and run the gpc demo programs and a couple of more complex programs of mine (which use grx24 and the cephes libml library). Everything is okay. If your previous gpc on djgpp was old the first idea is to check: you have gcc2952b you have the sections [gpc] and [gpcpp] in djgpp.env (in particular [gpcpp] was [gpc-cpp] in older gpc versions) I have bnu210. Do you have an older ? In principle this should make no difference with gcc2952. Differences come with 2953 Hope this helps.
I have the latest of everything (ie, more or less the same as you have). Like I said, gcc works perfectly, and so does everything else (except gpc when a program uses directly or indirectly the gpc unit). So I am not quite sure what the problem is. Are there any djgpp issues with NT4 or Win2000?
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/
I have the latest of everything (ie, more or less the same as you have). Like I said, gcc works perfectly, and so does everything else (except gpc when a program uses directly or indirectly the gpc unit). So I am not quite sure what the problem is. Are there any djgpp issues with NT4 or Win2000?
Yes with Win2000 (besides the LFN problems). I have no more looked to c.o.m.djgpp recently, but AFAIR you can launch no more than a ridiculously small (2) number of subprocesses: rhide is not able to compile even gcc programs for that reason: it adds an extra level. But I have no machine to check. Hope this helps.
Maurice
On 27 Mar 2001, at 11:42, Maurice Lombardi wrote:
I have the latest of everything (ie, more or less the same as you have). Like I said, gcc works perfectly, and so does everything else (except gpc when a program uses directly or indirectly the gpc unit). So I am not quite sure what the problem is. Are there any djgpp issues with NT4 or Win2000?
Yes with Win2000 (besides the LFN problems). I have no more looked to c.o.m.djgpp recently, but AFAIR you can launch no more than a ridiculously small (2) number of subprocesses: rhide is not able to compile even gcc programs for that reason: it adds an extra level. But I have no machine to check. Hope this helps.
Thanks. It at least helps me know not to bother about djgpp on Win2K. I still don't know why I have compilation problems with GPC though. It is not a big problem because I use Cygwin and Mingw anyway - I just wanted to be able to test some stuff under djgpp as well.
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/
On Mon, 26 Mar 2001, Maurice Lombardi wrote:
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
[..]
Has anybody tried to compile gpc with gcc2953 on a linux machine?
Have linux I586 box. While gcc2953 is broken, it *seems* to work. Programs without units compile and work ok. For programs with units, found a work-around.
Using crtdemo.pas as an example:
gpc --automake -c crtdemo.pas gpc -o crtdemo crt.o crtdemo.pas
Hope this helps Russ
On Mon, 26 Mar 2001, Russ Whitaker wrote:
On Mon, 26 Mar 2001, Maurice Lombardi wrote:
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
[..]
Has anybody tried to compile gpc with gcc2953 on a linux machine?
Have linux I586 box. While gcc2953 is broken, it *seems* to work. Programs without units compile and work ok. For programs with units, found a work-around.
Using crtdemo.pas as an example:
gpc --automake -c crtdemo.pas gpc -o crtdemo crt.o crtdemo.pas
Peter, here's a suggestion:
In module.c, where the .gpi file gets loaded add the following:
If not automake and not have_c then load the corresponding .o file so linker can find it
If error: "ERR: <filename> not found. Precompile unit or use automake."
So with precompiled units "gpc -o foo foo.pas" should work just fine. That still leaves a problem with automake and, sorry, for that one I don't have a clue.
Russ
Maurice Lombardi wrote:
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
Briefly speaking:
when applying the patch contained in the p/diff directory (I have taken the same diff as for gcc-295 -2951 -2952 which are identical), I get the following messages
C:\djgpp\gnu\gcc-2.953\gcc>patch -p1 < p\diffs\gcc-2.95.3.diff patching file "expr.c" Hunk #1 succeeded at 4505 (offset 75 lines). Hunk #3 succeeded at 4542 (offset 75 lines). patching file "fold-const.c" Hunk #1 succeeded at 1462 (offset 1 line). patching file "stor-layout.c" patching file "tree.c" Hunk #1 succeeded at 5025 (offset 39 lines). Hunk #3 succeeded at 5100 (offset 39 lines). patching file "tree.h" Hunk #1 succeeded at 1631 (offset 1 line). patching file "tree.def"
No hunk fails, so I proceed with a 3 stage bootstrap. Seems OK but when running dostest it crashes midway, after lots of errors the log file is on agnes:
ftp://agnes.dida.physik.uni-essen.de/home/maurice/make.2953.out
It appears that:
all failed programs include units, either by an explicit uses clause in the main, by a --uses= compilator option or even throug $L there are error messages gpc.exe: installation problem, cannot exec `cpp': No such file or directory (ENOENT)
That happens if the programs use C files (directly or indirectly, e.g. via CRT), or does it also happen if they just use Pascal units?
indeed cpp has been renames cpp0 in this release.
I haven't looked at gcc-2.95.3 yet, but you might want to try replacing `cpp' by `cpp0' in gpc.c, lines 713, 749, 777, 795, 826, 862, 884, 897, 921, 949.
The other problems (to me) don't look cpp related. Maybe the diffs went wrong, or there are more serious differences. Probably only Peter can tell...
Frank
Frank Heckenbach wrote:
ftp://agnes.dida.physik.uni-essen.de/home/maurice/make.2953.out
indeed cpp has been renames cpp0 in this release.
I haven't looked at gcc-2.95.3 yet, but you might want to try replacing `cpp' by `cpp0' in gpc.c, lines 713, 749, 777, 795, 826, 862, 884, 897, 921, 949.
OK it makes all the messages about cpp disappear. But the others pertaining to units remain. The error file on agnes has been updated: ftp://agnes.dida.physik.uni-essen.de/home/maurice/make.2953.out
In looking to those error messages: frequently the error messages are said to be errors in the main while they pertain obviously to the unit. Identifiers in the error messages seem frequently to be the last part of some identifier in the unit. Looks like if the file of the unit had not been properly read and somewhat overlay the main. Hope this helps Maurice
On Mon, 26 Mar 2001, Maurice Lombardi wrote:
Mr. Veli Suorsa wrote:
Thanks for your reply!
ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2952b.zip
OK. I try to always give under this same link the lastest gpc snapshot I have compiled, and which give zero error when running the whole test suite.
I just updated gcc-2.95.3 version of Djgpp. Every other compiler seems to work well (Thanks to Andris).
Can You update this Pascal compiler (gpc2953b.zip) and documentation and inform me (download site), too?
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
I testetd with gpc-20010317
Briefly speaking:
when applying the patch contained in the p/diff directory (I have taken the same diff as for gcc-295 -2951 -2952 which are identical), I get the following messages
C:\djgpp\gnu\gcc-2.953\gcc>patch -p1 < p\diffs\gcc-2.95.3.diff patching file "expr.c" Hunk #1 succeeded at 4505 (offset 75 lines). Hunk #3 succeeded at 4542 (offset 75 lines). patching file "fold-const.c" Hunk #1 succeeded at 1462 (offset 1 line). patching file "stor-layout.c" patching file "tree.c" Hunk #1 succeeded at 5025 (offset 39 lines). Hunk #3 succeeded at 5100 (offset 39 lines). patching file "tree.h" Hunk #1 succeeded at 1631 (offset 1 line). patching file "tree.def"
No hunk fails, so I proceed with a 3 stage bootstrap. Seems OK but when running dostest it crashes midway, after lots of errors the log file is on agnes:
ftp://agnes.dida.physik.uni-essen.de/home/maurice/make.2953.out
I had many failures also.
It appears that:
all failed programs include units, either by an explicit uses clause in the main, by a --uses= compilator option or even throug $L there are error messages gpc.exe: installation problem, cannot exec `cpp': No such file or directory (ENOENT)
indeed cpp has been renames cpp0 in this release.
perhaps we should have p/diffs/gcc-2.95.3.diff where this is fixed
I have include in djgpp.env a [cpp0] identical to [cpp] (and kept [cpp] to be sure. No change.
Looking in the changelog I find indeed
2000-12-18 Zack Weinberg zackw@Stanford.EDU:
- Makefile.in: Rename cpp to cpp0, tradcpp to tradcpp0, and xcpp to cpp throughout. (native): Remove unnecessary dependency on cpp.
- gcc.c (C specs): Call cpp0 to do preprocessing, not cpp.
- ch/lang-specs.h, cp/lang-specs.h, f/lang-specs.h,
objc/lang-specs.h: Call cpp0 to do preprocessing, not cpp.
The corresponding change to p/lang-specs.h has not been done of course. Could it be the only change to do ?
I have no more clue.
I think this renaming is understandable to avoid having executable with the same name (cpp.$exeext) in 2 directories. I have seen related trouble with DJGPP port of gcc-2.95.X (before 2.95.3) and avoided it by leaving $prefix/bin/cpp.exe out of gcc295Xb.zip.
Has anybody tried to compile gpc with gcc2953 on a linux machine?
Yes. I tried. I run into some trouble when GPC_FOR_TARGET was not passed from top level make to one in gcc subdirectory as ./xgpc -B./ is wring for Canadian crosses of course. As result make fails in gcc/p/rts. I added definition of GPC_FOR_TARGET in t op level makefile and passing it make in subdirectories.
I use bnu210 (and have suppressed accordingly the various -mno-bnu210 in djbuild1.sh). djgpp v2.03 in a W98 dos box. I have first installed gcc2953b.zip and compiled with it.
If You want -mno-bnu210 to be usefull at all, You should use binutils-2.8.1 or 2.9.1. For gcc-2.95.3 I made -mbnu210 the default and added warning when -mnu-bnu210 is being used.
Now we have one more trouble with DJGPP port of gcc-2.95.3: -gcoff seems to be broken
Unfortunatelly it was not detected before uploading files to ftp.delorie.com. Otherwise I should have to consider it as showstopper ...
Andris
Andris Pavenis wrote:
perhaps we should have p/diffs/gcc-2.95.3.diff where this is fixed
concatenate p/diffs/gcc-2.95.diff and the following:
---------------------------------------------------------------------
*** gcc-2.953/p/gpc.c.orig Tue Feb 27 13:09:54 2001 --- gcc-2.953/p/gpc.c Tue Mar 27 11:51:20 2001 *************** static struct compiler default_compilers *** 710,716 **** {"@c", { #if USE_CPPLIB ! "%{E|M|MM:cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 710,716 ---- {"@c", { #if USE_CPPLIB ! "%{E|M|MM:cpp0 -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** static struct compiler default_compilers *** 746,752 **** %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! "cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 746,752 ---- %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! "cpp0 -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** static struct compiler default_compilers *** 774,780 **** #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 774,780 ---- #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:cpp0 -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** static struct compiler default_compilers *** 792,798 **** {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ --- 792,798 ---- {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp0 %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ *************** static struct compiler default_compilers *** 823,829 **** %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ --- 823,829 ---- %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp0 -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ *************** static struct compiler default_compilers *** 859,865 **** {".c", {"@c"}}, {"@c", { ! "cpp -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 859,865 ---- {".c", {"@c"}}, {"@c", { ! "cpp0 -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** static struct compiler default_compilers *** 881,887 **** %{!pipe:%g.s} %A\n }}}}" }}, {"-", ! {"%{E:cpp -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 881,887 ---- %{!pipe:%g.s} %A\n }}}}" }}, {"-", ! {"%{E:cpp0 -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** static struct compiler default_compilers *** 894,900 **** %{!E:%e-E required when input is from standard input}"}}, {".m", {"@objective-c"}}, {"@objective-c", ! {"cpp -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__OBJC__ -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 894,900 ---- %{!E:%e-E required when input is from standard input}"}}, {".m", {"@objective-c"}}, {"@objective-c", ! {"cpp0 -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__OBJC__ -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** static struct compiler default_compilers *** 918,924 **** {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 918,924 ---- {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp0 %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** static struct compiler default_compilers *** 946,952 **** %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -undef -$ %{!undef:%p %P} -D__ASSEMBLER__ \ --- 946,952 ---- %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp0 -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -undef -$ %{!undef:%p %P} -D__ASSEMBLER__ \
--------------------------------------------------------------------
But this is not the end of the story
Andris Pavenis wrote:
I think this renaming is understandable to avoid having executable with the same name (cpp.$exeext) in 2 directories. I have seen related trouble with DJGPP port of gcc-2.95.X (before 2.95.3) and avoided it by leaving $prefix/bin/cpp.exe out of gcc295Xb.zip.
Yes, this seems a reasonable change (I've also run into problems because of the different cpp's before), and as far as I understood Maurice, that's rather easily fixed in GPC, but the serious problems seem unrelated...
Has anybody tried to compile gpc with gcc2953 on a linux machine?
Yes. I tried. I run into some trouble when GPC_FOR_TARGET was not passed from top level make to one in gcc subdirectory as ./xgpc -B./ is wring for Canadian crosses of course. As result make fails in gcc/p/rts. I added definition of GPC_FOR_TARGET in t op level makefile and passing it make in subdirectories.
That's strange since currently GPC doesn't use GPC_FOR_TARGET at all. Make-lang.in, l. 140-141:
RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`"
I think we did this exaclty because of the problem you described.
Do you perhaps have an older GPC version which does not have this?
Frank
-
Andris Pavenis -
Frank Heckenbach -
Maurice Lombardi -
Mr. Veli Suorsa -
Prof. A Olowofoyeku (The African Chief) -
Russ Whitaker