[NCLUG] 32 bit app, 64 bit OS

[Bob Proulx]

Stephen Warren wrote:
> grant at amadensor.com wrote:
> > I am wondering the pitfalls of running 32 bit applications on 64 bit Linux.
> 
> In general, 32-bit applications run fine on 64-bit hosts, at least as
> far as e.g. interaction with the Linux kernel.

Agreed.  I have done exactly this above quite a bit and there isn't
any intrinsic problem with doing it.  Mostly it will just work.

> The issue is that your 32-bit application will need 32-bit libraries.

First off, try it (on a test system) and depending upon a variety of
things it will Just Work.  In 95% of the cases you will be up and
running and done at that point.  As Stephen said it is all about
having the libraries available.

What do you do about the remaining 5% of the cases where you have to
fish because it doesn't work for some reason?  Let me say a few words
about what I do for the problem cases.

I frequently use one of two different solutions in the case where
there are problems getting libraries.  The first is to set up a full
32-bit chroot containing a copy of the 32-bit system.  This will run
fine on the 64-bit kernel.  In the chroot I can install and apply
security upgrades and so forth for the entire 32-bit system.  The
32-bit libraries won't be a problem there.  This even works across
different types of systems such as RHEL/Debian and so forth, within
the limits of kernel ABI capabilities.  Both systems must be able to
use a common kernel.  You can even copy the previous system and use it
as a chroot.  That has the advantage of having everything all
installed and configured without needing to hash that out again.

The disadvantages of doing a full system chroot are that it is a whole
additional system to keep updated for security upgrades.  In order to
make it completely happy it will need /proc and /dev and other
directories 'bind' mounted into the chroot so that applications there
will work as if they are running from the base system.  Depending upon
things you will need to set up so that mail works correctly and this
may need cron to be running in the chroot.  It is potentially a full
system.  That adds admin effort to keep track of everything.  But it
works really well.

In some ways the full chroot is like a VPS VM but in other ways it is
more integrated and so you are further along the path of migrating to
the newer system.  Since it isn't a separate VM you can have newer
fully ported applications call the legacy un-ported application and
scripts can run relatively seemlessly back and forth without realizing
that one of the programs is running in the chroot and another is not.
Then over the development cycle you can pull things out of the chroot
and when you are done you can expunge the chroot and move on without it.

Bob