[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: