I know, xpdf and gv do a nice job with PDF most of the time, but sometimes you need the real deal. So I forced the (ia32) acroread package from marillat onto my amd64 system. While it does works fine inside of an ia32 chroot, it does not work when it is installed in the (amd64) root. Since I am not a big fan of running anything in chroot, I went to explore the issue. It seems to be pretty generic, so I think it might hit other applications, too.
All problems are related to the dynamic loading of shared modules (libdl/dlopen). This is not a surprise: while you can tell ld.so to look for the right libraries in /emul/ia32-linux/lib, the path for dynamic loading is set by the library itself, and still pointing to the "wrong" directory. As a seasoned "real programmer", I have solved this with a hex editor, but I would not recommend that :-) 1. The modules in /usr/lib/gconv cannot be loaded, because they are amd64 of course. Setting GCONV_PATH=/emul/ia32-linux/usr/lib/gconv should be sufficient. I have filed a bug with ia32-libs, because I think this should be fixed during the build process. 2. gtk-2.0 is required, which is not included in ia32-libs. If you copy it from a chroot installation (or include a chroot in /etc/ld.so.conf), gtk pixbuf does not work, because it tries to load format specific modules from /usr/lib/gtk-2.0/2.4.0/loaders. Since it only loads the xpm module, maybe Acrobat works without this. 3. And pango looks for its modules in /usr/lib/pango/1.4.0/modules, which is again wrong. It should be possible to override that with a new configure file and by setting PANGO_RC_FILE, but I was never really successful in configuring pango, so I let somebody else figure that out. I imagine that any executable that uses gnome runs into the same problems, so fixing them would be very useful. Including gnome in ia32-libs (or creating ia32-gnome-libs) seems like the way to go. I know how difficult it is to compile gnome, so I don't envy the packager. In the long run, I think we need multiarch to take care of this. The problem is that the path of loadable modules is specified in configuration files. I think this is a very bad idea, but gnome does it extensively. So either a better way of finding loadable modules has to be found and implemented in gnome, or multiarch has to differentiate configuration files, too. Thomas