Bug 156982 - Fix multilib compat-arch bonobo in FC5
Summary: Fix multilib compat-arch bonobo in FC5
Alias: None
Product: Fedora
Classification: Fedora
Component: libbonobo
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
: 176034 (view as bug list)
Depends On:
Blocks: FC5Blocker 174316
TreeView+ depends on / blocked
Reported: 2005-05-05 20:47 UTC by Bill Nottingham
Modified: 2014-03-17 02:53 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-20 16:53:15 UTC
Type: ---

Attachments (Terms of Use)

Description Bill Nottingham 2005-05-05 20:47:34 UTC

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.

Comment 1 Mark McLoughlin 2005-05-06 14:41:52 UTC
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

  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.

Comment 2 Jakub Jelinek 2005-05-06 14:50:21 UTC
$LIB in dlopen is supported in any glibc post 2002-09-26, i.e. 2.3.2 and later

Comment 3 Mark McLoughlin 2005-05-06 14:58:53 UTC
(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?

Comment 4 Jakub Jelinek 2005-05-06 15:01:16 UTC
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.

Comment 5 Alexander Larsson 2005-05-09 08:40:28 UTC
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
Getting that upstream might be easier.

Comment 6 Mark McLoughlin 2005-05-09 08:52:28 UTC
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

  $> /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.

Comment 7 Mark McLoughlin 2005-05-09 09:12:16 UTC
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)

Comment 8 Bill Nottingham 2005-05-16 21:39:28 UTC
Are we actually doing this for FC4?

Comment 9 Ray Strode [halfline] 2005-05-18 19:09:15 UTC
Mark, are you going to do this or would you like one of us on the core team to
do it?

Comment 10 Mark McLoughlin 2005-05-19 06:19:37 UTC
I can do the actual packaging fixes if someone goes through the 4 steps above on
a ppc machine and verify it actually works.

Comment 11 Warren Togami 2005-05-19 06:26:15 UTC
(ping dwmw2, read above)

Comment 12 David Woodhouse 2005-05-19 06:48:20 UTC
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?

Comment 13 Mark McLoughlin 2005-05-19 07:09:08 UTC
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.


    * 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. 


    * 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 

Comment 14 David Woodhouse 2005-05-22 12:09:08 UTC
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. 

Comment 15 Jeremy Katz 2005-05-23 17:57:08 UTC
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...

Comment 16 Mark McLoughlin 2005-05-24 11:43:56 UTC
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

-       -DSERVERINFODIR=\"$(libdir)/bonobo/servers\" \
+       -DSERVERINFODIR=\"$(serverinfolibdir)\" \

Then tweak the following .server files:


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

Comment 17 Jeremy Katz 2005-05-25 18:38:24 UTC
For FC4, let's stick with not shipping them.  But let's get this in for FC5

Comment 18 Jeremy Katz 2006-01-09 23:38:53 UTC
This still needs doing for FC5...

Comment 19 Bill Nottingham 2006-01-09 23:45:53 UTC
Assining to someone other than me so it gets done. :)

Comment 20 David Woodhouse 2006-01-12 16:22:06 UTC
*** Bug 176034 has been marked as a duplicate of this bug. ***

Comment 21 David Woodhouse 2006-01-12 18:22:04 UTC
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.

Comment 22 Ray Strode [halfline] 2006-01-12 18:49:33 UTC
Hi David,

It seems likely, yea.

Comment 23 Ray Strode [halfline] 2006-01-19 01:51:01 UTC
Updated list of packages that ship shared lib bonobo components:


Comment 24 sangu 2006-01-19 11:13:07 UTC
Installing libbonobo-2.13.1-4
applets can't be loaded on gnome-panel.

$ rpm -q gnome-applets gnome-panel

Installing evolution-2.5.4-9
bonobo component can't be built  on 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:

(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:
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


Comment 25 Jakub Jelinek 2006-01-19 11:39:24 UTC
glibc dynamic linker only expands $LIB and ${LIB}, not $(LIB).  ld.so is not
make ;).  Ray, can you please fix up the spec files?

Comment 26 Chris Chabot 2006-01-19 12:20:50 UTC
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

Comment 27 Ray Strode [halfline] 2006-01-19 13:25:03 UTC
Sorry about that guys, fixes running through the build system now.

Comment 28 Ray Strode [halfline] 2006-01-19 13:31:05 UTC
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

Comment 29 Ray Strode [halfline] 2006-01-20 15:35:41 UTC
Hey Jeremy, David,

Is this fixed on powerpc now with the latest rawhide?

Comment 30 David Woodhouse 2006-01-21 10:20:44 UTC
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.

Comment 31 David Woodhouse 2006-02-07 09:39:54 UTC
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

Comment 32 David Woodhouse 2006-02-07 10:00:21 UTC
Booting without selinux and forcibly removing libbonobo.ppc64 and reinstalling
the 32-bit version is still sufficient to 'fix' this.

Comment 33 Paul Nasrat 2006-02-13 18:35:00 UTC
Again still failing on 20060212 still fails - have machine here I can show you on.

Comment 34 Jeremy Katz 2006-02-13 18:43:02 UTC
Would be really good to have this fixed in test3...

Comment 35 Ray Strode [halfline] 2006-02-13 19:36:26 UTC
I guess it already missed the test3 boat unfortunately.  I will definitely
reinvestigate soon.

Comment 36 Matthias Clasen 2006-02-20 16:53:15 UTC
All fixed in rawhide, according to Ray

Note You need to log in before you can comment on or make changes to this bug.