gpc for Solaris 2.5.1_(re)

Tue, 10 Sep 96 17:52:35 CST

On Tue, 10 Sep 1996 11:12:16 -0400 (EDT), 
M BAILEY   wrote:

>
>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...
>

If you can build a ready-to-run compiler we would be happy to distribute it.
There is no merged source tree: you put gpc and gcc in their own 
directory.

Because I have not updated the INSTALL file for a while, I shall shortly 
explain what to do: (I assume solaris is properly supported bu GCC)

If you extract gcc-2.7.2.tar.gz and gpc-1.2-2.7.2.tar.gz from the same 
location, you get gcc-2.7.2 and gpc-1.2-2.7.2 subdirs, which is just fine.

1) configure and build gcc:
        ./configure 
        make CFLAGS=-O2 LDFLAGS=-s LANGUAGS=c

If this fails, build gcc with -O0 and build a stage2 compiler with this 
the stage1 gcc, then go on (this is all explained in GCC manuals)

2) configure gpc:
        ./configure

configure should be able to find the gcc directory if it is reasonably 
"close". If not, run configure --help and see what options you must give it.

3) build gpc:
        make CFLAGS=-O2 LDFLAGS=-s


Read earlier notes about what to do if VPATH troubles strike (below).

BSD/SYSV signal confusion (RTS won't build) *may* be avoided by using a 
newer configure (message posted this list a few minutes ago)
If not, I would like to know whether configure decides you have SYSV or BSD 
(and if you know if this is incorrect, possibly see your  and 
.

4) A binary distribution can be created with the "make bindist" command.
I'm not familiar with the habbits of solaris pkgtools, so you may have to 
tweak it by hand (you should know this).


Hope this helps,
JanJaap



>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   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 (j.j.vanderheijden@student.utwente.nl)