Re: sparc64 and sparc architecture -- any consensus?
On Tue, May 11, 1999 at 03:04:06AM -0400, Adam Di Carlo wrote:
> Nils has asked me to do a content merge of the sparc64 and sparc
> porting web pages. I wish we were clearer in our mind exaclty how
> sparc64 is going to work.
Please merge them, it is the best solution.
> The last consensus I remember is that the situation is that most
> packages work fine in 32-bit emulation mode, and recompiling the whole
> shbang for 64-bit wasn't really worthwhile. As such, it seems that we
> were leaning towards a "derivative architecture" approach, in which
> one a few packages need to be specific to sparc64: egcs64,
> kernel-image, and maybe number-crunch intensive applications that
> really derived benefit from being 64-bit.
The way sparc64 is going to work is pretty much already planned out by
the egcs and glibc programmers. Sparc64 will cohabitate in a sparc32
environment. There will be a /lib64:/usr/lib64 (not sure where the
includes go, perhaps they remain the same for both?). The compiler for
sparc64 will be able to generate 32bit and 64bit binaries (seems it
always does 64bit by default, I'm checking into that), so it will only
take mere compile CFLAG changes to make it compile/link as a 64bit
> The head-scratching aspect of this idea is that dinstall, wanna-build,
> etc., don't support this concept. In fact, it would be almost easier
> to just let the autobuilders crunch away and do a full 64-bit port.
> Anyhow, I think getting fundamental consensus on what exactly we're
> doing for sparc64 is a very important early step.
I think what we will end up doing is making binary-sparc packages with
libc6-64, libc6-dev-64, etc. They will install even on sparc platforms
(since sparc32 can compile sparc64 programs, just not execute them, the
egcs to compile 64bit programs will be a sparc32 binary). Doing a full
port will make sparc64 useless since it wont be able to run any of the
sparc32 binaries (ie. netscape) and the size increase of the binaries
will make it overly huge.
> The other issues which are unclear in my mind, and which I would need
> to know about, is how the fundamental toolchain (glibc, egcs, ldso) is
> doing w.r.t. sparc-64 support. Reading back in the archives, the only
> indicators I see is:
> * glibc should be basically there (??)
Glibc claims to be sparc64 ready, I've been able to compile some simple
(simple meaning no libm functions, due to egcs) statically.
> * egcs not quite there (grab from ultrapenguin needed)
Egcs is missing only the floating-point functions in libgcc. I've
been keeping an eye on the CVS and there may be something there soon.
> * binutils not quite there (grab from ultrapenguin needed)
Binutils _is_ ready, has been ready and requires nothing more right now
than installing bintuils-multiarch to use the support. This is what has
been used for the sparc64 kernels.
> * xserver accellorated for Creator FB not yet merged
I believe Steve Dunham has been working with the X Strike Force to get
the Creator support tested and merged into the main X packages
So where we stand now is:
a) Get a working egcs that compiles sparc64 glibc with no problems
(I've got this already setup to package when the CVS is ready). I think
we will boot strap with the current egcs64 package and eventually move
to making the egcs64 compiler be able to replace the standard egcc
depending on whether or not we can get it to default to sparc32.
b) Once that is done I can work with Joel on getting sparc64 specific
compile options into the glibc tree to make -64 packages of the
I think once we have a development environment setup, we take a
breather, then decide what binary packages need to be build as 64 bit
(there shouldn't be many) and work with the maintainers to setup a build
system to produce both packages when compiled on sparc's.
----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <firstname.lastname@example.org> Debian GNU/Linux
OpenLDAP Dev - email@example.com The Choice of the GNU Generation
------ -- ----- - - ------- ------- -- ---- - -------- - --- ---- - --