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

Re: AMD response about Debian x86-64 port

Bart Trojanowski <bart@jukie.net> writes:

> I will assume that if we do any work we must start with a 64-bit kernel.

Patches available from ftp://ftp.x86-64.org/pub/linux-x86_64/

> From what I understand, the hardware provides a "64-bit long mode" in
> which the kernel could run and allow for 32-bit applications to execute
> without recompilation (this later mode is referred to as compatibility
> submode of long mode).


> However, recalling Andi Kleen's talk at OLS two years ago, I believe
> that a recompile will still be needed for these 32-bit apps due to
> an ABI change on the x86-64 platform.

ia32 apps work as-is, even binary-only stuff like the acrobat reader.

> There may be some apps that will (initially) not work in 64-bit
> mode, and for these we use 32-bit mode.  The only snag with this is
> that we now need two glibc's on the system: the 32-bit one and the
> 64-bit one.

That biarch thing (i.e. have 64bit and 32bit apps happily coexist on
the system) is actually a non-trivial issue.  One way to handle this
is to place 32bit shared libraries into $prefix/lib and the 64bit ones
into $prefix/lib64.  SuSE does it this way, I think the toolchain
(gcc, binutils + friends) want it this way too.  This has a number of
intresting consequences through:

 * The package file lists are not fixed any more because libdir
   depends on the build architecture.  Plenty of packages likely must
   be touched to deal with this.

 * Maybe it is possible to simply reuse the i386 debs for the 32bit
   personality.  That likely requires some (probably non-trivial)
   changes in dpkg and apt.



Gerd Knorr <kraxel@debian.org>

Reply to: