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.