Re: ia32 user space on ia64, et al
On Mon, Jun 04, 2001 at 04:05:42PM -0600, Bdale Garbee wrote:
> I'm currently thinking through the issues involved in getting ia64 support
> from where it is now to something we can release joyfully. One of the big
> issues is how we should support ia32 user space applications and libraries
> on ia64. Since this is perhaps only the first of several potential multi-
> architecture situations facing us, I'd like to help motivate a general solution
> to the problem.
> Other distributions are handling this for ia64 in various ways, none of which
> seem "right" to me. TurboLinux has a single .rpm that delivers a subset of
> the ia32 libraries from their distribution repackaged to install in a
> subdirectory instead of in /. Redhat apparently has updated RPM to do
> on-the-fly path translation for ia32 binary .rpm's when they are installed on
> an ia64 system. In all cases, the dynamic loader is smart enough to pick the
> right library routine from the right architecture once ld.so.conf is loaded
> with the real paths to all the libraries in question.
Welcome to Sparc64's delima. I've been contemplating and fighting this
for almost a year now.
Sparc64 is backwards though, since it is an addon for sparc. IOW, the
64bit libs go into /lib/64 and /usr/lib/64. I've started out by
supplying libc6-sparc64 and libc6-dev-sparc64 packages. Also, there is a
gcc-3.0-sparc64 and libgcc0-sparc64 (these just enable -m64 for the
So that's what I've been doing. It seems the only real choice for me.
ia64 has it much worse, since you don't want to have duplicate 32bit
packages for ia32 and ia64 (with the location of the libs being the only
difference). Sparc64 doesn't have this duplication, luckily.
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` firstname.lastname@example.org -- email@example.com -- firstname.lastname@example.org '