sparc64 and sparc architecture -- any consensus?
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.
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 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.
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 (??)
* egcs not quite there (grab from ultrapenguin needed)
* binutils not quite there (grab from ultrapenguin needed)
* xserver accellorated for Creator FB not yet merged
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: