ia32-libs alternatives
I have been using a technique which others may find beneficial.
Not all applications are ported to ia64. Many are not 64-bit clean.
Some will compile but will trigger segmentation violations when run.
It is desirable to run the ia32 version of some applications.
Since ia64 can execute x86 code if the shared libraries are available
it is an easy matter to 'apt-get install ia32-libs' and be able to run
legacy ia32 applications. The ia32-libs package installs ia32
libraries into /emul/ia32-linux/* and sets the appropriate directories
in /etc/ld.so.conf. On the surface, things work well.
However, as documented in the package README there are a number of
issues with that method. Keeping those libraries up to date appears
ad-hoc at the moment. Installing additional libraries is an involved
process. But there are alternatives. Here is the seed for one here.
http://people.debian.org/~walters/chroot.html
Ah, the chroot area. This has potential to alleviate the problems of
maintaining the chroot. I have been setting up the chroot area for
woody ia32. This way I can use apt in a native apt mode to keep the
ia32 binaries up to date. Things have been working pretty well. But
things are not completely without issues. Let's see how it works.
I have never been able to get the debootstrap process to work
cross-platform. Therefore I first build the chroot natively on a ia32
platform following the documented process above using debootstrap.
Then second I copy the chroot onto the ia64 machine.
sudo rsync -a /woody/ root@ia64box:/woody-ia32/
At this time the instructions can be resumed immediately after the
debootstrap. The ia32 chroot area can be updated with a full stable
release or updated to sid as is your preference. I personally do not
mount /proc as suggested in the chroot setup reference. Without /proc
I tend to avoid collisions when some daemon packages try to kill the
running daemons and start new ones in the chroot.
sudo chroot /woody-ia32
apt-get update
apt-get install packages
apt-get upgrade
Great! But running in the chroot is not as friendly when you are
trying to enable it for compatibility mode. Here are the final
steps. Edit /etc/ld.so.conf and change the library paths to be
similar to the following.
/usr/X11R6/lib
/woody-ia32/usr/lib
/woody-ia32/lib
/woody-ia32/usr/X11R6/lib
Then run 'ldconfig' (or 'ldconfig -v') to update the runtime link
cache.
ldconfig -v
What happens next depends upon whether you have ia32-libs installed or
not. If you do then you have a symlink from /lib/ld-linux.so.2 to
/emul/ia32-linux/lib/ld-linux.so.2 which should work fine. But since
my goal was to replace that methodology with this alternative I
removed or have not installed ia32-libs on my machines. In which case
we need to make our own symlink to our own ia32 chroot area.
sudo ln -fns /woody-ia32/lib/ld-linux.so.2 /lib/ld-linux.so.2
At this time it is possible to run all of the ia32 legacy applications
which may not have been ported to native ia64. It is possible to set
PATH to fall into the ia32 directory.
PATH=$PATH:/woody-ia32/usr/bin
Now when updates are needed to be installed one can run the normal
commands to update the chroot area. This is the key benefit of this
alternative technique to the ia32-libs package. The maintenance of
the ia32 binaries are done using normal techniques familiar to the
administrator.
sudo chroot /woody-ia32
apt-get update
apt-get -u upgrade
Will all applications work this way out of the box? No. Any
application which needs files rooted in / will not find them. For
example, openoffice will look for /etc/openoffice and not find it
since it is really installed in /woody-ia32/etc/openoffice in the
install area. Similar for /usr/lib/openoffice. In order to make
those applications work you will need to create a symlink to the
install location. But even large applications seem capable. An
openoffice woody ia32 backport installed in the woody ia32 chroot runs
fine in the normal ia64 environment using this method.
Am I completely satisfied with this technique? Pretty much. But not
completely. I don't like the symlinks that I have created which are
not managed by the package manager. They were needed to make the
packages find /etc/ conffiles. But when it comes time to install
native applications those will get in the way and need to be cleaned
up first. I should instead create an adaptor symlink deb package
which conflicts with the real native package so that when the native
package becomes available and is installed the adaptor symlinks will
be automatically removed. But I am lazy and this worked sufficiently.
I hope this has been of benefit. I am interested in any feedback or
comments which this list discussion might generate.
Bob
Reply to: