Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Dec 1998 12:24:33 -0800 (PST)
From:      Christopher Nielsen <enkhyl@scient.com>
To:        Alfred Perlstein <bright@hotjobs.com>
Cc:        Paolo Di Francesco <paipai@tin.it>, freebsd-sparc@FreeBSD.ORG
Subject:   Re: Experiments...
Message-ID:  <Pine.BSF.4.05.9812141206440.420-100000@ender.sf.scient.com>
In-Reply-To: <Pine.BSF.4.05.9812141135270.27793-100000@bright.fx.genx.net>

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)?
 
> > 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?

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