Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

[Daniel Jacobowitz <dan@debian.org>]

On Tue, Jan 13, 2004 at 09:29:31AM -0500, Stephen Frost wrote:
> * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) wrote:
> > The reason for /lib 32 bit and /lib64 64 bit is to keep compatibility
> > to i386 compiled programs. I don't know how IA64 handles its /lib32
> > subdir but they probably have some magic in there that fails if
> > binaries are compiled with some uncommon options (like setting rpath).
> 
> Now, now, let's not be stupid here.  The reason for /lib 32bit is to
> keep compatibility with *broken* i386 binary-only programs.  The loader
> can certainly handle having a /lib32, there's only a problem when there
> are hard-coded paths in the binary that can't be changed (which is done
> using -rpath I think, if anyone actually uses it with system paths?).
> 
> > On amd64 the only real reason for 32 bit support is compatibility with
> > the old i386 stuff and binary-only stuff so breaking it even once is
> > not realy acceptable to a lot of people.
> 
> You can still be compatible with i386 and have a /lib32 except in the
> broken-binary case.  Personally no one has actually demonstrated such a
> case to me yet, but I've heard they exist.

Sorry, but you're so wrong.  First of all, the string
"/lib/ld-linux.so.2" is hard-coded into every dynamic ELF binary, which
rather limits your choice of library directories.  Secondly, the use of
RPATH is more common than you think; libtool still generally causes it
(no comment on that practice).  There are a number of other
case-by-case problems also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer