Re: ppc64 port
On Wed, Apr 28, 2004 at 09:09:08AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2004-04-27 at 23:36, Cajus Pollmeier wrote:
> > Hi!
> > Just a simple query... I _may_ have a chance to get a ppc64
> > machine. Is anyone interested in such a port?
> > I know that it basically works with the 32 bit binaries, but the
> > installation is non trivial right now and having no 64 bit code
> > isn't optimal, too.
> Well, the later is not true. 32 bits code tend to run faster than 64
> bits code on ppc64. Unlike amd64 where you win by having access to more
> registers, on ppc64, you just end up having to use more instructions to
> load a full constant in a register ;)
> Overall, we can go the gentoo way, and do a full 64 bits debian
> distribution independant from the 32 bits one, or we can simply do like
> other distributions do, and I think it makes some sense, is to have a biarch
> The main lot of packages stays 32 bits. But we need a biarch gcc and the 2
> libcs. Then, for each libxxxx package, we can build both the ppc and the ppc64
> deb and they can be both installed at the same time.
> But the first thing to have is a 64 bits kernel. That we really want. For
But which you will not get without a 64 bit gcc, which in turn needs a
64bit glibc which in turn needs 64bit kernel headers, and probably a
working gcc ...
> that, we need to be able to build it. So the first thing that need to be done
> is to have a biarch toolchain. gcc 3.4 can be compiled biarch, but doing the
> "initial" biarch build is very difficult. Once you already have the 2 glibcs
> installed, it's simply a matter of rebuilding each bit normally, but if you
> don't, the initial "bootstrap" is a can of worm.
I have a version of the gcc-3.4 package in experimental who tries to
build biarch. It fails because of lacking 64bit headers though.
> So somebody should take the time into doing that, producing .deb's that can
> be installed, and once they are installed, it's easy to rebuild & update to
> later versions etc...
> (glibc cannot easily be cross-compiled/bootstraped, this is the root of
> the problem, the glibc maintainer doesn't consider that as an important