Re: AMD response about Debian x86-64 port

[Arnd Bergmann <arnd@bergmann-dalldorf.de>]

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.

It gets even worse if you want to package -dev debs that you can install
coexistant. Imagine a package with

foo     -> /usr/bin/foo, /usr/share/doc/foo-1.0/*
libfoo1 -> /usr/lib/libfoo.so.*, /etc/libfoo.conf, /usr/share/foo/...
libfoo1-dev -> /usr/include/foo*.h, usr/lib/libfoo.{a,so}, ...

Instead of these three packages, you might now need seven:

foo(64 or 32 bit) depends on libfoo1 (same bits),  -> /usr/bin/foo, ...
libfoo1-support -> /etc/libfoo.conf, /usr/share/foo/..
libfoo1(32bit) depends on libfoo1-support -> /usr/lib/libfoo.so.*
libfoo1(64bit) depends on libfoo1-support -> /usr/lib64/libfoo.so.*
libfoo1-headers         -> /usr/include/foo*.h
libfoo1-dev(32bit) depends on libfoo-headers and libfoo(32bit) 
		-> /usr/lib/libfoo.{so,a}
libfoo1-dev(64bit) depends on libfoo-headers and libfoo(64bit) 
		-> /usr/lib64/libfoo.{so,a}

	Arnd <><