Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Dec 1998 15:47:38 -0500 (EST)
From:      Alfred Perlstein <bright@hotjobs.com>
To:        Christopher Nielsen <cnielsen@pobox.com>
Cc:        Paolo Di Francesco <paipai@tin.it>, freebsd-sparc@FreeBSD.ORG
Subject:   Re: Experiments...
Message-ID:  <Pine.BSF.4.05.9812141531290.27793-100000@bright.fx.genx.net>
In-Reply-To: <Pine.BSF.4.05.9812141206440.420-100000@ender.sf.scient.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, 14 Dec 1998, Alfred Perlstein wrote:
> 
> > this is a pain, you'll need to set your path to the bin-util's bin
> > directory, you'll also have to compile like so:
> > 
> > (this assumes you configured with --prefix=/usr/local/sparc64)
> > 
> > export C_INCLUDE_DIR=/usr/include
> > export LD_LIBRARY_PATH=/usr/local/sparc64/sparc64-elf/bin
> > export PATH=/usr/local/sparc64/sparc64-elf/bin:/usr/local/sparc64/bin
> > 
> > gmake LANGUAGES="c c++"
> >
> > hopefully that'll work, however you'll be generating invalid elf binaries
> > without Kapil Chowksey's and my patches.  i still haven't exactly decided
> > on what to use for our compiler, i'm temped to use egcs-current as
> > supposedly the sparc back end is way better, however egcs1.1.1 is now
> > supposedly branded "stable" moving between revisions shouldn't be too bad.
> 
> I succeeded in building binutils-2.9.1 and egcs-19981206 over the weekend.
> The snapshot of egcs compiled with no problems, but that doesn't mean it's
> generating correcct code. I've successfully generated both .o and .S files
> from a small test program, but FreeBSD file(1) thinks it's a 64-bit ELF
> RS6000 binary (I think this is already known). Is this because the
> compiler is generating incorrect code? Have you posted your patches to the
> list (I know Kapil Chowksey has)?

Kapil's kernel beginnings are here:

ftp://janus.baldcom.net/pub/FreeBSD/Sparc/kernel/src-981023.tar.gz 

my patches to egcs are at home, this is an authorized ftp site.  I
talked to the admin and he will allow us to use janus.baldcom.net.

Special thanks to Ken McKittrick for the space. :)

anything people want to dump here (for the port) can go into:

ftp://janus.baldcom.net/pub/FreeBSD/Sparc/incoming/

a small readme file for what it is would be appreciated.

top level for the ftp is:

ftp://janus.baldcom.net/pub/FreeBSD/Sparc/

i will upload KC's and my work on egcs tonight.

> > > My idea is to have 2 toolchains. The first one to test "compiler" and
> > > the second one to use it on code. We don't know much about
> > > egcs/gcc/etc. so I thought to test compiler/toolchain on a usable
> > > platform (Solaris). This mean the first toolchain (I called it
> > > SolarSystem) must be used _only_ to test the compiler, and the second
> > > one (EatIt) must be used to do our test when SolarSystem works.
> > 
> > this is less of an issue than just getting code done. :)  there are
> > workarounds for invalid asm code.  moving between revisions of egcs to get
> > correct code will stink but they already test their own work, we shouldn't
> > need/try to duplicate their efforts.
> 
> Agreed. Let the egcs team worry about quality control on their end. They
> seem to be doing a good job, so far.
> 
> > i'm trying to merge in Kapil's kernel work into the tree i have at home...
> > have you downloaded it? 
> 
> I should grab this and we should synch trees at some point. Where is
> Kapil's work?

At home, i will upload our patches to the site mentioned above.

I understand you are using egcs-current? it is essential that we use the
same toolchain, i think i will get the latest snap tonight and hope for
the best.  (we really need the sparc bits that are in the -current snap)

-Alfred

> -- 
> Christopher Nielsen
> Scient: The eBusiness Systems Innovator
> <http://www.scient.com>;
> cnielsen@scient.com
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-sparc" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9812141531290.27793-100000>