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

Re: Concerns about AMD64 port



John Goerzen <jgoerzen@complete.org> writes:

> On Thu, Feb 05, 2004 at 05:02:53PM +0100, Goswin von Brederlow wrote:
> > John Goerzen <jgoerzen@complete.org> writes:
> > > > Our big goal is to support A) pure 32bit i386, B) mixed 32/64 bit
> > > > i386/amd64 and C) pure 64bit amd64 userspace.
> > > 
> > > If a pure 64bit userspace is the goal, why does the AMD64 ports page say
> > > such a thing is "academical and of little use"?
> > 
> > Because the 64bit only userspace will be the mixed userspace with the
> > 32 bit stuff missing. It will still be the 64bit part of the mixed
> > systems. That means e.g. that libs are in /lib64/ and /usr/lib64/.
> 
> Uhm, that strikes me as solely a rhetorical device.  A mixed userspace
> without the 32-bit stuff is, by definition, a pure 64-bit userspace :-)
> 
> In fact, the only thing at all that I can see that is different about
> this than any other pure 64-bit system is the names of the lib
> directories.  The naming of the lib directories has no bearing on
> whether a platform is 64-bit or not.  I could build a pure 64-bit AMD64
> Linux distro that calls it /Library and it will still be 64-bit.
> 
> Plus, it's trivial to make changes to autoconf and debhelper that would
> probably get 90% of the packages to put their libs in the right place.
> 
> > Developing a standalone 64 bit system thats incompatible to the mixed
> > system is work wasted.
> 
> I am not suggesting that.
> 
> > > B seems like the toughest thing to accomplish.  Wouldn't it make more
> > > sense to get C done first, and then once the 64-bit userspace is
> > > functional, add on the 32-bit emulation?
> > 
> > No, you would have to throw it away to change to a mixed mode. The
> > problem is getting the 64bit stuff out of the way of the 32 bit stuff
> > and not compiling for 64 bit.
> 
> Why would you have to throw it away?  If the only problem really is the
> /lib64 thing, that's not hard to fix.

The problems are more complex. Read up on the past discussions here
and on debian-devel. Most places you have to change to get lib64
working you also have to change again later for the multiarch
support. You would have to fix the same files and lines twice so the
first time around is just wasted.

> > > > For some crucial things likes libc6 it doesn't look like we can get
> > > > rid of the 32bit flavour though. But apart from a bit of bloat here
> > > 
> > > Are you saying that libc6 cannot build as a 64-bit package?
> > 
> > No, it just looks to complex to build a standalone 64 and 32 bit
> > package that also work together. Currently the 64bit package depends
> > on the 32 bit package. For something as essential as libc6 thats fine
> > for now.
> 
> Why is that?  that's just weird.
> 
> > /lib/ -> lib64/,... , one arch -> multiarch
> 
> So we put everything in /lib64 now, and add on /lib later.
> 
> > Solving the problem just for amd64 by ignoring the 32bit support would
> > be a hell of a lot easier but work wasted when multiarch replaces it.
> 
> I still don't buy that.  If the problem really is the location of libs,
> that is not a tough nut to crack for a single arch.
> 
> -- John

The problem is how to package it all up with minimal changes to apt,
dpkg, dselect, dpkg-dev, aptitude and of cause all sources.

MfG
        Goswin



Reply to: