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

Re: Debian for x86-64 (AMD Opteron)

At Wed, 9 Apr 2003 23:08:31 +0200,
Michael Banck wrote:
> > Note that the x86_64 is special: It would be relatively easy to bootstrap
> > a port on the actual hardware, but doing it right requires changing _all_
> > library packages as well as many other packages. The problem is that
> > we want binaries to be compatible with i386 as well as with other x86_64
> > distributions and that requires the installation of both 32 and 64 bit
> > libraries at the same time.
> FWIW, we can probably discuss how to do an x86-64 port in the right
> way[tm] *NOW*, we don't need access the hardware for this.

I fully agree.

Moreover, this discussion is needed for architectures which can handle
both 32bit and 64bit binaries for a long time.  Currently glibc has
already sparc64 and s390x port, but we will have x86_64, in addition
probably ppc64 and mips64 (I have been interested in this area
especially for maintaining glibc package).

Currently only glibc and gcc has special handling for sparc64 and
s390x.  Almost all libraries are not concerned, so most applications
on sparc64 and s390x are worked under 32bit.  32 bit is sufficient for
almost personal users, but it's not for commercial use and probably
future personal use (for handling large DVD/blueray movie data or so).

I think generic 64bit libraries should put on {/lib64, /usr/lib64/,
/usr/local/lib64, /usr/X11R6/lib64, ...}. Debian 64bit architecture
packages should have only 64 bit libraries because it saves storage,
and once we prepare 64bit port, we have no need to use 32bit
binaries/libraries.  To use 32 bit old libraries, dpkg and apt may
be needed to modify handling both 32 bit and 64 bit packages like:

	apt-get install libgtk2.0-0(32) libgtk2.0-0
	dpkg -i libgtk2.0-0_ver_i386.deb libgtk2.0-0_ver_x8664.deb

Well the version number "ver" should be same in 32/64 bit version.
The above issue is only for generic libraries, and I have not
considered how to handle glibc/gcc package yet.

BTW, my concern about x86_64 issue is intel's 64bit extension (not
ia64).  If they plan to release 64 bit version i386, and it's
different architecture from x86_64 (so XEAX is not existed, for
example), we should not think that x86_64 is only 64 bit version of
i386 (and i386 packages are shared between x86_64 and intel's i386

-- gotom

Reply to: