On Mon, 9 Sep 1996 21:44:50 +0200 (MET DST), Peter Gerwinski peter@agnes.dida.physik.uni-essen.de wrote:
Hi Phil, Brad, and Jan Jaap,
stor-layout & friends ARE BACK ...
I wish that was true. Here is the results on my machine. maybe_find_function_data gpc-parse.o [...] dbxout_set_type_status gpc-decl.o
I know that problem. It is a bug in make, Jan Jaap and I had hoped to have worked around. The problem is that there are language independend source files which exist in the GPC source as well as in the GCC source. In Makefile, look out for stor-layout.o, dbxout.o, ..., toplev.o. For some reason, they are not recompiled correctly.
What happens precisely is that "make" has a VPATH: it looks for object code in the gcc object directory too. When your gcc object directory is identical to your gcc source directory, make thinks $gccbin/foo.o is uptodate because it depends $gccbin/foo.o on $gccsrc/foo.c (which it can see because $gccsrc=$gccbin) Then it doesn't build ./foo.o based on $gpcsrc/foo.c (mind $gpcsrc vs $gccsrc)
To make it more complicated, VPATH behaviour of various "make" programs is different and some versions of GNU make have VPATH bugs.
To work around, you can create these *.o files and copy them into the gcc directory, so "make gpc" will find and use them.
Use different directories for $gccsrc and $gccbin. Or delete the ones in $gccbin to force make to rebuild them.
/janjaap
--- The latest & greatest in software, hardware and manswear. Bono Vox (U2)
If someone sends me a merged source tree of GCC and GPC i would be happy to compile them into a finished binary product and possible build solaris pkg's out the resulting answers to that you can install them with out needing any other utilities...
Matthew S. Bailey
On Tue, 10 Sep 1996, J.J. van der Heijden wrote:
On Mon, 9 Sep 1996 21:44:50 +0200 (MET DST), Peter Gerwinski peter@agnes.dida.physik.uni-essen.de wrote:
Hi Phil, Brad, and Jan Jaap,
stor-layout & friends ARE BACK ...
I wish that was true. Here is the results on my machine. maybe_find_function_data gpc-parse.o [...] dbxout_set_type_status gpc-decl.o
I know that problem. It is a bug in make, Jan Jaap and I had hoped to have worked around. The problem is that there are language independend source files which exist in the GPC source as well as in the GCC source. In Makefile, look out for stor-layout.o, dbxout.o, ..., toplev.o. For some reason, they are not recompiled correctly.
What happens precisely is that "make" has a VPATH: it looks for object code in the gcc object directory too. When your gcc object directory is identical to your gcc source directory, make thinks $gccbin/foo.o is uptodate because it depends $gccbin/foo.o on $gccsrc/foo.c (which it can see because $gccsrc=$gccbin) Then it doesn't build ./foo.o based on $gpcsrc/foo.c (mind $gpcsrc vs $gccsrc)
To make it more complicated, VPATH behaviour of various "make" programs is different and some versions of GNU make have VPATH bugs.
To work around, you can create these *.o files and copy them into the gcc directory, so "make gpc" will find and use them.
Use different directories for $gccsrc and $gccbin. Or delete the ones in $gccbin to force make to rebuild them.
/janjaap
The latest & greatest in software, hardware and manswear. Bono Vox (U2)
-
J.J. van der Heijden -
M BAILEY