Success with Acrobat Reader 7.0 (tweaking module pathes)
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
Reply to: