http://intranet.corp.redhat.com/ic/intranet/BonoboActivationMultilibFoo.html So, for RHEL 4 we removed everything that used bonobo from compat arch as much as possible. We haven't done that for FC4 until now; I'm working on this. For release, we need to make sure this is complete. Alternatively, we can fix bonobo-activation-server as Jakub suggested, in which case we should put the libraries back.
The fix Jakub talks about is an interesting idea - I never knew about that dlopen() feature. It would involve: 1) Going through and changing every .server file for shlib components so that the library path uses $LIB - e.g. /usr/$LIB/bonobo/monikers/foo.so These are spread out amongst evo, nautilus, gnome-vfs2, gedit, file-roller, gnome-bluetooth, gnome-spell, gtkhtml3, libbonobo and libgnome 2) Changing 64 bit version of bonobo-activation-server to look at the registry in /usr/lib/bonobo/servers as well as the registry in lib64 3) Making sure it actually works as we expect :-) To get the fix upstream, we'd also need to know on which platforms the dlopen() $LIB feature is supported and probably hack up a libbonobo-activation patch for those platforms that don't support it.
$LIB in dlopen is supported in any glibc post 2002-09-26, i.e. 2.3.2 and later releases.
(In reply to comment #2) > $LIB in dlopen is supported in any glibc post 2002-09-26, i.e. 2.3.2 and later > releases. Yeah, I'm more wondering about dlopen() from other libcs and the other platforms gmodule supports like win32 etc. Its glibc-only, then?
Yes, it is glibc only. On the other hand, most systems (except Irix and Solaris I think) don't have lib+lib64 or similar multilib schemes.
One could do a similar fix without relying on glibc. You'd just pass the $LIB string from the daemon to the client, and the client library could expand it. Since 32bit and 64bit clients use different versions of the client library the client can resolve it using a compile time define (set by autoconf). Getting that upstream might be easier.
Yeah, probably make sense to only do that on systems where glibc doesn't support it, though. So, if anyone wants to verify this actually works, you could do: 1) Make sure you've a 64 bit bonobo-activation-server installed 2) Go through /usr/lib*/bonobo/servers and replace any /usr/lib or /usr/lib64 path with /usr/$LIB 3) Add the /usr/lib/bonobo/servers registry to bonobo-activation by running $> /usr/sbin/bonobo-activation-sysconf --add-directory=/usr/lib/bonobo/servers 4) Log in and see what happens If that works, we can then just go ahead and patch the packages.
It would also need to be a 32 bit nautilus, gnome-session etc. to make sure its fixed. (i.e. no point testing the above on x86-64)
Are we actually doing this for FC4?
Mark, are you going to do this or would you like one of us on the core team to do it?
I can do the actual packaging fixes if someone goes through the 4 steps above on a ppc machine and verify it actually works.
(ping dwmw2, read above)
Yeah, OK. It was about time I updated a ppc64 machine to FC4. Bearing in mind that on PPC uses ppc32 as the primary architectures and ppc64 only for compatibility (the reverse of x86_64/i386) which version of bonobo-activation-server do you want me to have installed?
You want the 64 bit version of bonobo-activation From BonoboActivationMultilibFoo: === The bonobo-activation package contains the bonobo-activation-server daemon. Part of what b-a-s does is return the path to shlib components which applications then load. In mixed 32/64 bit environments, this causes major headaches. Essentially, you need to ensure that if all bonobo using apps are running in 32 bit mode, then b-a-s is also running in 32 bit mode or if they're all running in 64 bit mode, then b-a-s must be running in 64 bit mode. ppc64: * All bonobo using apps run in 32 bit * We don't ship multilib packages for bonobo-activation and its dependants * Thus, its always a 32 bit b-a-s running * If someone builds a 64-bit package that wants to use bonobo-activation: o it will cause the 64-bit libraries to be included via deps o this will cause the 64-bit version of bonobo-activation-server to run o the world breaks. x86-64 * Most bonobo using apps run in 64 bit * OpenOffice.Org is the main exception * Thus, we have both i386 and x86-64 bonobo-activation packages installed * Happily, the x86-64 bonobo-activation-server binary always wins * So, the only problem is if OpenOffice.Org (or any other bonobo app running in 32 bit mode) tries to use shlib bonobo components then the shlib component just won't work (the shlib loading will fail) * We think and hope and pray that it isn't a problem in practice, though ===
Sorry, it took me longer than expected to update the ppc64 machine to rawhide because the $@%!& installer can no longer install from the rsync'd rawhide tree on the local hard drive -- it insists on ISO images for some reason. Will attempt to do this on Monday.
Tried this out on a g5 here and following the steps above, things seem to work. Even tested running evolution and it was able to come up fine. So I think it's time to start changing packages...
Okay, I've got the fixes ready, need to figure out if we've still time to do this. libbonobo hack is to patch activation-server/Makefile.in with: +serverinfolibdir = $(libdir)/bonobo/servers +ifneq ($(libdir), $(exec_prefix)/lib) +serverinfolibdir := $(serverinfolibdir):$(exec_prefix)/lib/bonobo/servers +endif - -DSERVERINFODIR=\"$(libdir)/bonobo/servers\" \ + -DSERVERINFODIR=\"$(serverinfolibdir)\" \ Then tweak the following .server files: evolution:GNOME_Evolution_Addressbook_2.2.server evolution:GNOME_Evolution_Addressbook_LDIF_Importer_2.2.server evolution:GNOME_Evolution_Addressbook_VCard_Importer_2.2.server evolution:GNOME_Evolution_Calendar_2.2.server evolution:GNOME_Evolution_Calendar_Importer_2.2.server evolution:GNOME_Evolution_Mail_2.2.server file-roller:File_Roller_Component.server gedit:GNOME_Gedit.server gnome-bluetooth-libs:GNOME_Bluetooth_Component.server gnome-spell:GNOME_Spell.server gnome-vfs2:GNOME_VFS_Moniker_std.server gtkhtml3:GNOME_GtkHTML_Editor-3.6.server libbonobo:Bonobo_Moniker_std.server libgnome:GNOME_Moniker_std.server With this in %install: for serverfile in $RPM_BUILD_ROOT%{_libdir}/bonobo/servers/*.server; do sed -ie 's|location="/usr/lib\(64\)*/|location="/usr/$(LIB)/|' $serverfile done
For FC4, let's stick with not shipping them. But let's get this in for FC5
This still needs doing for FC5...
Assining to someone other than me so it gets done. :)
*** Bug 176034 has been marked as a duplicate of this bug. ***
Presumably this is what caused my graphical login to a newly-installed FC5t2 to fail completely, as described in bug #176034? After removing libbonobo.ppc64 and at-spi.ppc64 and forcibly reinstalling their ppc32 counterparts, it works again.
Hi David, It seems likely, yea.
Updated list of packages that ship shared lib bonobo components: evolution: /usr/lib64/bonobo/servers/GNOME_Evolution_Addressbook_2.6.server /usr/lib64/bonobo/servers/GNOME_Evolution_Calendar_2.6.server /usr/lib64/bonobo/servers/GNOME_Evolution_Mail_2.6.server gnome-spell: /usr/lib64/bonobo/servers/GNOME_Spell.server gnome-vfs2: /usr/lib/bonobo/servers/GNOME_VFS_Moniker_std.server gtkhtml3: /usr/lib64/bonobo/servers/GNOME_GtkHTML_Editor-3.8.server libbonobo: /usr/lib/bonobo/servers/Bonobo_Moniker_std.server libbonoboui: /usr/lib64/bonobo/servers/Bonobo_Sample_Controls.server libgnome: /usr/lib64/bonobo/servers/GNOME_Moniker_std.server rhythmbox: /usr/lib64/bonobo/servers/Rhythmbox_Nautilus_Context_Menu.server
Installing libbonobo-2.13.1-4 applets can't be loaded on gnome-panel. $ rpm -q gnome-applets gnome-panel gnome-applets-2.13.2-2 gnome-panel-2.13.5-1 Installing evolution-2.5.4-9 bonobo component can't be built on evolution. $evolution (evolution:5073): evolution-shell-WARNING **: Cannot activate 'OAFIID:GNOME_Evolution_Addressbook_Component:2.6': g_module_open of `/usr/$(LIB)/evolution/2.6/components/libevolution-addressbook.so' failed with `/usr/$(LIB)/evolution/2.6/components/libevolution-addressbook.so: cannot open shared object file: No such file or directory' (evolution:5073): evolution-shell-WARNING **: Cannot activate 'OAFIID:GNOME_Evolution_Memos_Component:2.6': g_module_open of `/usr/$(LIB)/evolution/2.6/components/libevolution-calendar.so' failed with `/usr/$(LIB)/evolution/2.6/components/libevolution-calendar.so: cannot open shared object file: No such file or directory' (evolution:5073): evolution-shell-WARNING **: Cannot activate 'OAFIID:GNOME_Evolution_Tasks_Component:2.6': g_module_open of `/usr/$(LIB)/evolution/2.6/components/libevolution-calendar.so' failed with `/usr/$(LIB)/evolution/2.6/components/libevolution-calendar.so: cannot open shared object file: No such file or directory' (evolution:5073): evolution-shell-WARNING **: Cannot activate 'OAFIID:GNOME_Evolution_Calendar_Component:2.6': g_module_open of `/usr/$(LIB)/evolution/2.6/components/libevolution-calendar.so' failed with `/usr/$(LIB)/evolution/2.6/components/libevolution-calendar.so: cannot open shared object file: No such file or directory' (evolution:5073): evolution-shell-WARNING **: Cannot activate 'OAFIID:GNOME_Evolution_Mail_Component:2.6': g_module_open of `/usr/$(LIB)/evolution/2.6/components/libevolution-mail.so' failed with `/usr/$(LIB)/evolution/2.6/components/libevolution-mail.so: cannot open shared object file: No such file or directory' (evolution:5073): e-utils-WARNING **: can't load plugin '/usr/lib/evolution/2.6/libecontactlisteditor.so.0: undefined symbol: addressbook_load' (evolution:5073): e-utils-WARNING **: can't load plugin '/usr/lib/evolution/2.6/plugins/liborg-gnome-default-mailer.so: undefined symbol: em_utils_prompt_user' (evolution:5073): e-utils-WARNING **: can't load plugin '/usr/lib/evolution/2.6/components/libevolution-calendar.so: undefined symbol: mail_tool_uri_to_folder' libnm_glib_get_nm_state(): org.freedesktop.DBus.Error.ServiceUnknown raised: The name org.freedesktop.NetworkManager was not provided by any .service files libnm_glib_get_nm_state(): org.freedesktop.DBus.Error.ServiceUnknown raised: The name org.freedesktop.NetworkManager was not provided by any .service files (evolution:5073): evolution-shell-WARNING **: Unknown component mail And
glibc dynamic linker only expands $LIB and ${LIB}, not $(LIB). ld.so is not make ;). Ray, can you please fix up the spec files?
Was also bitten by the errors mentioned in comment #24 Manually editing those files and replacing $(LIB) with $LIB fixed things up & everything is functioning correctly again
Sorry about that guys, fixes running through the build system now.
By they way, you can work around this in the mean time by doing: for f in /usr/lib*/bonobo/servers/*.server; do sed -ie 's|$(LIB)|$LIB|' $f; done
Hey Jeremy, David, Is this fixed on powerpc now with the latest rawhide?
I'm away and unable to test now until early February. Since I'm currently on dial-up, I can't easily even do it remotely. I can give access if someone else wants to try remote X though.
A clean rawhide-20060206 install still has totally non-functional GNOME. Much like the screenshot at https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122371
Booting without selinux and forcibly removing libbonobo.ppc64 and reinstalling the 32-bit version is still sufficient to 'fix' this.
Again still failing on 20060212 still fails - have machine here I can show you on.
Would be really good to have this fixed in test3...
I guess it already missed the test3 boat unfortunately. I will definitely reinvestigate soon.
All fixed in rawhide, according to Ray