[m-dev.] building the current compiler on sparc

[Erwan Jahier]

| On 24-Feb-1999, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
| > 
| > For 3 or 4 days now, I don't manage to build the current Mercury compiler on
| > sparc (SunOS cripure 5.7 Generic sun4u sparc SUNW,Ultra-250). Whereas on
| > Linux (Linux averell 2.0.34 #2 Thu Jul 9 10:57:48 EST 1998 i686 unknown), it
| > works ok. 
| 
| Which version of gcc are you using?

I have tried both

[15:25]%gcc -v
Reading specs from /usr/local/gcc-2.8.1/lib/gcc-lib/sparc-sun-solaris2.7/2.8.1/specs
gcc version 2.8.1

and 

[15:23]%gcc -v
Reading specs from /usr/local/gcc-2.7.2.1/lib/gcc-lib/sparc-sun-solaris2.6/2.7.2.1/specs
gcc version 2.7.2.1

| Also, just to make absolutely sure, when you say the "current"
| Mercury compiler, do you mean the latest version in the cvs repository?

Yes.

| And what mmc options are you compiling it with?

No particular options. I've just executed "configure; mmade depend; mmake;"


| > 
| > Note: at that stage on Linux (i.e. when the compilation arrives to the point
| > "rl_code.c:45173: warning: right shift count >= width of type ...." messages
| > are displayed), the machine is swapping very hard.
| > 
| > Does it fail to compile on sparcs because the the machine is overloaded ?
| 
| It's possible.  Fatal signal 11 is SIGSEGV.  This can result from
| the program running out of C stack space.
| 
| > What can I do ?
| 
| Check your ulimits e.g. using the sh/bash command `ulimit -a'.

Well it is set to 8192 kbytes for both sparc and linux.
I set it to 16384 kbytes: same problem.

| Examine all the limits, but pay particular attention to the stack limit.
| Examine the resources used by the cc1 process when it dies, using
| `ps' and/or `top'.
| 
| You can do "mmake EXTRA_CFLAGS='-v -Q -save-temps'"; this will show you
| the exact way in which cc1 is being invoked.  Then you can invoke cc1
| manually, inside gdb; presuming that your cc1 excecutable hasn't been
| stripped, this will allow you to see exactly where it is dying. 
| By examining the location and the values of the nearby data, you should
| be able to see why it is dying, e.g. due to stack overflow, dereferencing
| a null pointer, or whatever.
| 
| (If your cc1 has been stripped, you can download the gcc source and do
| 
| 	zcat gcc*.tar.gz | tar -xf - &&
| 	cd gcc* &&
| 	sh configure &&
| 	make CFLAGS=-g cc1
| 
| to create one with debugging information.)

:-(
Ok, I'll do that...

Thanks Fergus.

-- 
R1.