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

Re: AMD response about Debian x86-64 port

Arnd Bergmann wrote:
On Friday 10 January 2003 17:20, Gerd Knorr wrote:

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

Yes, there appears to be a broad consensus on this. Apart from SuSE,
it is also done the same way in Red Hat beta (x86_64 and s390x at
least) and Debian on s390. See also http://www.pathname.com/fhs/2.2/fhs-4.8.html

There are still two possible variants: - 64 bit distribution with 32bit compat libraries in $prefix/lib
  (SuSE and RH on X86_64 and s390x)
- 32 bit distribution with 64bit kernel and compat code in $prefix/lib64
  (Debian on s390, and AFAIK anything on Sparc64)

(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.

This can be further broken down into subproblems:
- A package has /usr/lib or similar hardcoded in its Makefiles and needs
  to be patched in order to link correctly (e.g. tcl)
- A package has $prefix/lib hardcoded in its Makefile and needs to be
  patched in order to install correctly (e.g. db4)
- A package uses dlopen on a hardcoded path containing /lib (e.g. pam)
- A package always tries to link against a library in $prefix/lib, when
  it is present in both $prefix/lib and $prefix/lib64, thereby preventing
the building of both variants on the same system (e.g. libjpeg or anything that brings its own libtool) - The actual file list contains references to $prefix/lib - all of the above ;-)

* 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.

What do you presently do for other 64-bit architectures that support 32-bit binaries? E.g., UltraSparc, that can run Sparc binaries?

____               .:.                 ____
Bryan W. Headley - bwheadley@earthlink.net

Reply to: