LWN.net Logo

The 64-bit question

June 16, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

It was probably too much to hope that all Linux vendors would take the same approach to their distributions for AMD's 64-bit x86 chips and Intel's forthcoming 64-bit x86 chips, or x86_64. While the major commercial vendors (SUSE, Red Hat and Mandrake, to name a few) are shipping mixed distributions for x86_64, the recently-announced Debian x86_64 port is a pure 64-bit distribution without 32-bit libraries.

A pure 64-bit distribution has the advantage of being simpler, and of not having to worry about multiple versions on libraries and such. Thus, while other distributions have relegated the 64-bit libraries to an alternate location, such as /usr/lib64, the Debian project ships with 64-bit libraries in /usr/lib and avoids the problem of rewriting package creation rules to install libraries in /usr/lib64 or a similar situation. However, this results in a system that is unable to run 32-bit x86 binaries.

The original plan for Debian's x86_64 port was to be similar to sparc64, where the default is 32-bit applications and libraries. However, the tide turned in February, and multiarch support was put on the back burner. As Goswin von Brederlow explains:

There was an attempt at doing a mixed port but the resistance by the dpkg developers and the community in general was too big to get it under way, esspecially with the sarge release looming over our heads. A full mixed port means changing every single library package and affects probably all packages. That's nothing one wants to do before sarge.

So instead of going full 32/64 bit mixed mode amd64 in one big step pure64 was started to get 64 bit support fully available with minimum impact to sarge. Merging is multiarch support for mixed 32/64 bit is now step 2 planed for after sarge at the earliest.

This may not end up being a big problem, even for those users who need to run 32-bit x86 applications. As John Goerzen points out, it is possible to run 32-bit binaries in a chrooted environment:

The only reason I can see for even bothering to support 32-bit applications at all is for binary-only proprietary software. And that is not such a concern; it takes all of about 10 minutes to set up a 32-bit chroot with debootstrap to run those things in.

Some have voiced concerns about Debian being incompatible with other x86_64 distributions. Since LSB-compatibility should be the main concern, we wondered whether Debian, or any other Linux distributions, were compatible with the LSB specification for x86_64 chips. Stuart Anderson, lead developer of the LSB written specification, told LWN that none of the distributions currently meet the LSB specification, but for obvious reasons:

That's because there has not yet been an official release of the LSB for that architecture. There is a draft, and it will get released in the very near future, but because it hasn't been, distros have not yet had a chance to certify.

Anderson did say that a distribution can be LSB-compliant, without running 32-bit binaries, since the specification covers only x86_64. He also said that they are working on a "multi-arch" specification, "but it's not really far enough along to say anything specific."

In general, I think a 64 bit distro should be able to support a 32 bit runtime in parallel. It just does so as supporting two specs, and not a single one that mandated both 32 & 64.

No doubt, it will be some time before x86_64 support is uniform across all the various Linux distributions. The hardware is not yet in wide enough use to truly force distributions to standardize, and it's entirely possible that the 32-bit problem will disappear as x86_64 hardware becomes commonplace.


(Log in to post comments)

How to set up 32-bit support on Debian

Posted Jun 17, 2004 1:17 UTC (Thu) by BrucePerens (guest, #2510) [Link]

apt-get install debootstrap
mkdir /32
debootstrap sid /32
chroot /32
run 32-bit software.

Now, this can be made to run 32-bit executables without chroot. What we need to support that is for ld-linux.so to determine when it is being called from a 32-bit program. by reading its header, and transfer control to the 32-bit version. The 32-bit ld-linux.so would then prepend /32/ to all of the directories in the loader path.

Then, you would only have to chroot to run apt to update the 32-bit stuff.

This seems to be very viable, and should be done as a Debian package that sets up the proper environment and installs shell scripts to maintain it. A framable "Bruce Thinks You Rock" certificate will be awarded to the person who does this :-)

How to set up 32-bit support on Debian

Posted Jun 17, 2004 2:53 UTC (Thu) by ewen (subscriber, #4772) [Link]

Except that from within the chroot you can't access files that are outside the chroot (this being the raison d'etre of a chroot). So your 32-bit-program-in-chroot can't access, eg, your home directory. You can work around this by, eg, nfs mounting the relevant directories inside the chroot (or permanently locating them inside the chroot and symlinking from the outside in) but it can get to be non-trivial to maintain.

What might work better is a custom ld-linux.so which recognised 32-bit binaries and changed all their references to /lib, /usr/lib, etc to be references to /lib32, /usr/lib32, etc (in some cases just setting the library path for them may be sufficient).

Then all that would be needed is a dpkg modification (or a wrapper) that could intercept i386 library packages (ie 32-bit ones) as they were installed and put them into /lib32, /usr/lib32, etc. Plus perhaps some apt magic to allow installing both amd64 and i386 architecture packages on the same system.

FWIW, given Debian's release schedule -- roughly every 2 years or so now -- I suspect the problem will go away by itself before there's another (sarge+1) Debian release. So probably all that is needed is a simple-as-possible work around for use in Sarge.

Ewen

How to set up 32-bit support on Debian

Posted Jun 17, 2004 3:22 UTC (Thu) by busterb (subscriber, #560) [Link]

How about mount /home /32/home -obind; mount /proc /32/proc -obind ?
The bind option functions like a transparent symlink. Gentoo used to
recommend this during installation, which occurs in a chrooted
environment. You can do the same thing with other file systems or just
plain directories, like /var, /etc and /dev.

How to set up 32-bit support on Debian

Posted Jun 17, 2004 10:49 UTC (Thu) by stuart (subscriber, #623) [Link]

I read Bruce's post as wanting to remove the need to chroot an instead make ld.so smarter -- i.e. for a 32 bit binary pick the 32 bit libraries. This makes all your stated problems go away.

Stu.

How to set up 32-bit support on Debian

Posted Jun 17, 2004 21:06 UTC (Thu) by ewen (subscriber, #4772) [Link]

On re-reading Bruce's post I see that you are right -- he was suggesting that ld-linux.so should be doing library-path-modification (prepending /32). I was confusing it with other posts on this topic (eg, Debian mailing lists) where people were suggesting just running it in a chroot.

Bruce's approach (constant string prepended) is probably an easier hack than my approach (make ..../lib/... into .../lib32/...), and provides a more direct way to update the libraries (chroot /32; apt-get update && apt-get upgrade).

So it seems quite feasible.

Ewen

How to set up 32-bit support on Debian

Posted Jun 17, 2004 3:00 UTC (Thu) by jreiser (subscriber, #11027) [Link]

...ld-linux.so to determine when it is being called from a 32-bit program. by reading its header, and transfer control to the 32-bit version...

http://www.BitWagon.com/rtldi/rtldi.html seems to be a good start on that part.

How to set up 32-bit support on Debian

Posted Jun 17, 2004 5:20 UTC (Thu) by ncm (subscriber, #165) [Link]

John Reiser is always amazing. Thanks, John!

The 64-bit question

Posted Jun 17, 2004 6:47 UTC (Thu) by peterhoeg (subscriber, #4944) [Link]

Guys, it is actually much much simpler. Although the chroot solution gives you all the libs you could ever want, "apt-get install ia32-libs" will give you the most commonly used ones for use directly in a 64 bit environment.

The 64-bit question

Posted Jun 17, 2004 7:27 UTC (Thu) by droberge (guest, #10852) [Link]

Unfortunately ia32-libs is for an ia64 system not x86-64. Given that x86 binaries run under emulation on ia64 this approach probably won't work on x86-64 where the 32-bit binaries are run natively.

The 64-bit question

Posted Jun 17, 2004 17:31 UTC (Thu) by ballombe (subscriber, #9523) [Link]

The ability to run several distributions at the same time on one box is
terribly useful, it can solve almost any problems of distro compatibility.
It deserves to be more mainstream:
Consider:
1) You run Debian stable, but you can run programs from Debian unstable
when need be.
2) You normally run in 64bit mode but you want to run some 32bit only software.
3) You want to run some old binary only software that need libc5.
4) You want to build binaries for a distribution you don't normally use.

All that can be easily performed with a chroot. You can share the
home directories and allowing chroot'ed X11 programs to use the X server
with
mount --bind /home $CHROOT/home
mount --bind /tmp $CHROOT/tmp

The 64-bit question

Posted Jun 22, 2004 14:26 UTC (Tue) by utoddl (subscriber, #1232) [Link]

A completely different approach would be to have an ld.so that understood SDE (Semantic Dictionary Encoding) -- see Code Generation On-the-Fly: A Key to Portable Software [pdf]. Too bad this little known technology was so closely (and needlessly) tied to Modula-II. A set of SDE libraries wouldn't even need to be recompiled to make the jump from 32 to 64 bits. The SDE browser plug-in implementation made Java look silly in a side-by-side comparison. (Other interesting portable code links.) Oh well, what might have been...

Worse is better

Posted Jun 30, 2004 4:14 UTC (Wed) by xoddam (subscriber, #2322) [Link]

So many elegant solutions existed but never got widespread use.

At least they're good as proof-of-concept :-)

"Only" for closed-source programs?

Posted Jun 24, 2004 10:40 UTC (Thu) by forthy (guest, #1525) [Link]

I'd beg to differ. There are several reasons to run a mixed 32/64 bit system, even if you don't run any closed source program at all. The most obvious are the following:

  • You are a developer, and you want to create and test binaries for both 32 and 64 bit system without rebooting.
  • The free software you want to use has assembler parts which haven't been ported to x86_64 (yes, this happens, not everything can be written in GCC, think of a JIT).
  • The free software you want to use does support x86_64, but has some quirks there which don't show up on the 32 bit version.

For me, all three things are true. I'm a developer, and I don't want to reboot for testing 32 bit programs. The software I develop has assembler code parts, which don't work on x86_64 yet (that's because I'm still developing). Ah, and where it does work, it has quirks.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds