I was able to build kernel using 'somewhat' current gcc and=20
binutils. Suprisingly you can build and install that gcc on solaris
without specifying target platform, aka native solaris compiler
and (thanks to maintainers and developers team) that builds netbsd.

Everybody around says that that gcc cannot generate good code for sparc
so I don't use optimization at all. And I don't know if my current
problems with kernel related to this.

Funny I cannot build native solaris 64bit executable, which
runs.=20

Couple months ago Eduardo Horvath wrote nice instruction how-to
cross compile and that helped a lot. Thanks Eduardo.

--
=09Andrey

Oh, I'm not sure if that the case but I think you have to build and
install binutils first and gcc afterthat.

On Fri, 18 Aug 2000, ali (Anders Lindgren) wrote:

> Bringing up an ancient subject...
> (again, sorry if this isn't directly sparc64-related, but I'm
> running out of places to look).
>=20
> On Mon, 10 Jul 2000, David O'Brien wrote:
>=20
> > On Mon, Jul 10, 2000 at 01:08:46PM -0700, Eduardo Horvath wrote:
>       [ I wrote ]
> > > > I'm trying to build a cross-gcc that is able to build
> > > > 64bit Sparc v9 ELF binaries on SUN UltraSparc running Slowaris 2.7
> > > > in 32bit mode. I am trying to build it with gcc 2.8.1
> > >=20
> > > I would recommend using gcc 2.9.5.  sparc64 support in pre-egcs versi=
ons
> >                              ^^^^^^
> > 2.95.2.
>=20
> Right. I'm still on it, with 2.95.2. Since there's obviously a working
> port-sparc64 I assume there's some way of abusing gcc into producing
> 64bit binaries. :-) I first configured and built 64bit binutils without
> any problems (with --program-suffix=3D64). Then I did the following:
>=20
> $ export PATH=3D/where/my/binutils/are:${PATH}
> $ export LD_LIBRARY_PATH=3D/where/my/libs/go/lib:${LD_LIBRARY_PATH}
> $ export AR=3D`which ar64`
> $ export RANLIB=3D`which ranlib64`
> $ export LD=3D`which ld64`
> $ export CFLAGS=3D"-mpcu=3Dultrasparc -O2"
>=20
> When trying to build on..
>=20
> $ uname -a
> SunOS orff-6 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-5_10
>=20
> ..I occassionally get to the point where I get an "xgcc" binary which
> fails the test-suite on floating-point tests. Tonight I've been at it
> again, but the gcc build fails with the message:
>=20
> $ uname -a
> SunOS roman 5.7 Generic_106541-07 sun4m sparc SUNW,SPARCstation-5
> $ gmake
>=20
> <lotsajunk here>
>=20
> gcc -DCROSS_COMPILE -DIN_GCC -DHAIFA  -DSVR4  -mcpu=3Dultrasparc -O2
> -DHAVE_CONFIG_H  -o gencheck \
>  gencheck.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case
> "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo  ;; esac =
`
> ` case "" in ?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac `=20
> ./gencheck > tmp-check.h
> ./gencheck: syntax error at line 1: `(' unexpected
> gmake[1]: *** [s-check] Error 2
> gmake[1]: Leaving directory
> `/home/datlib/private/ali/gnu64/comp-build/gcc'
> gmake: *** [all-gcc] Error 2
>=20
> ..and that's about it. "gencheck" is some ELF-object that won't
> execute in the shell...
>=20
> So, it seems building works better if I do it on an UltraSparc
> (albeit running a 32bit kernel w/ 32bit tools) than cross-building
> on a Sparc5 (using the exact same tools).
>=20
> I'm not sure how to continue from here. Are there any NetBSD
> patches I could apply without patching it out of working
> on Solaris? (I will be doing development on a Solaris box on
> which I have no possibility to install NetBSD)
>=20
> Any ideas appreciated.
>=20
> --=20
> /ali: Computer Science Major and aspiring cartoonist. :-)=20
> (dept) dat94ali@ludat.lth.se - http://www.ludat.lth.se/~dat94ali
> (home) ali@h543.sparta.lu.se - http://h543.sparta.lu.se/
> * A4000/040-40/CV3D/Ariadne=B7AmigaOS=B7NetBSD=B7A3000/040-25/Ariadne *
>=20
>=20