On Sun, 2005-01-16 at 14:20 -0800, Nathan G. Grennan wrote:
> I fixed this issue by compiling i386 stuff on a i686 box at work. Pretty
> much the only things I wanted i386 were mozilla and galeon packages.
> Other things like mplayer I just installed the i386 version with yum
> from a repository.
AFAIK, there's no way to build i386 software of any complexity on
outside of an i386 chroot on an AMD64 system, without completely
modifying the package's build system.
> I have libonobo is installed for both 32bit and 64bit. One of the files
> in the packages in /usr/libexec/bonobo-activation-server. It is a 64bit
> executable. It tries to
> load /usr/lib64/bonobo/servers/GNOME_Galeon_Automation.server for the
> 32bit galeon which puts it in /usr/lib. So it isn't search both /usr/lib
> and /usr/lib64 like it should. This also brings up the issue of a lot of
> bad placement. GNOME_Galeon_Automation.server is a text file, so
> shouldn't it be in /usr/share or something else anyway. When I asked a
> galeon developer he said, yes, but that is where bonobo expects it.
>
Note that while .server files may be text, they describe binary
components. Thus, /usr/lib/bonobo lists 32-bit components
and /usr/lib64/bonobo lists 64-bit components. Their placement
in /usr/lib{,64} instead of /usr/share is correct.
Somebody should fix bonobo-activation to do the right thing on 64-bit
systems, but I don't think anybody really cares all that much about
Bonobo anymore.
> A galeon developer told me 32bit gtk programs on an FC3 x86_64 system
> were completely broken. When I asked for detail, he said that 32bit gtk
> programs trying to use libpixbuf would try to load 64bit themes.
Gdk-Pixbuf and GTK immodule problems on biarch systems were fixed for
FC3.
AFAICT, themes were never broken. Theme engines aren't specified as
paths to libraries, just strings which GTK uses to find the libraries.
At worst, 32-bit GTK programs will fail to find the requested theme
engine and revert to the default.
Certainly not "completely broken", especially on FC3 systems.
--
Nicholas Miell <nmiell@xxxxxxxxxxx>
