Re: sparcv9-2.95.2 update

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> Yesterday I reported a problem (included below) building a sparcv9-*-*
> compiler from 2.95.2 sources. I finally managed to build it, but there
> are two problems of which you might want to be aware.

Thanks for your update. As indicated before, the compiler is not
*supposed* to work, so don't be surprised if it doesn't. I recommend
not to use it, and to erase the installation from your hard disk. Can
I be more clear? :)

>    Details: I was running the 11/99 release of Solaris 2.7 with the
>    Maintenance patches installed. Patch 107058-01 was not installed.
>    I had no trouble building sparc-sun-solaris, just sparcv9-sun-solaris.
>    Seems the sparcv9-*-* compilers (stage1, stage2, final) put out code
>    that recent /usr/css/bin/as can't handle.

Ok. Somebody probably would need to analyse whether this is a bug in
the Sun assembler, or in gcc. If that isn't fixed in a release that
claims to support sparcv9, please re-report.

>  Indeed, the stage1 cccp.o looks wrong:
>
>	% find . -name cccp.o -exec file {} \; 
>	./gcc/cccp.o:   ELF 64-bit MSB relocatable SPARCV9 Version 1
>	./gcc/stage1/cccp.o:    ELF 32-bit MSB relocatable SPARC Version 1
>	%

No, that looks quite correct. If you use a sparc gcc as the bootstrap
compiler, you'll get a sparc32 executable in stage1. Stage 2 and stage
3 should be sparc64 executables.

>    Details: I had tried bootstrapping the compiler with a pre-compiled
>    2.95.2 from SunFreeware.Com as well as the sparc-sun-solaris I built.
>    Neither one worked. Then I got pre-compiled 2.95.1 sparcv9-sun-solaris
>    from a colleague and was able to build the compiler. Seems one can't
>    build sparcv9 without another 64-bit compiler to start with. I recommend
>    you make one available at GNU or Cygnus or SunFreeware.Com.

That won't happen. First, sparcv9 is not supported yet, so there is no
point in making binaries of a broken compiler available. Second, gcc
is capable to bootstrap with a different compiler; whether this is a
32-bit gcc, a 64-bit gcc, or something else should not matter.

I don't quite understand the lines

>	make[2]: Entering directory
>	             `/opt/local/src/gcc/gcc-2.95.2/sparcv9-sun-solaris/gcc'
>	gcc  -DIN_GCC -DHAIFA  -DSVR4  -g  -DHAVE_CONFIG_H
>	             -o cccp cccp.o cexp.o intl.o prefix.o version.o  mbchar.o
>                     obstack.o alloca.o       ../libiberty/libiberty.a
>	ld: fatal: file cccp.o: wrong machine class
>	ld: fatal: File processing errors. No output written to cccp

Apparently, this is the stage 1 build. How come there is still already
a cccp.o present? Did you not clean after a previous build attempt?
Since gcc (apparently) is a sparc32 compiler, it should not have ELF
64 objects as input. Which compiler had been producing these objects
in the first place?

As a related note: Please follow the guideline of using a separate
build directory; do not attempt to build gcc in its source directory.
That way, you can easily clean-up: Just throw-away the build
directory.

Hope this helps,
Martin