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/ [EMAIL PROTECTED]:/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
