GNOME Bugzilla – Bug 313122
Visibility of bonobo symbols
Last modified: 2014-11-13 17:50:25 UTC
Please describe the problem: The shared library libspi.dylib has many *_Bonobo_* symbols that are publicly visible when linking against this lib. Steps to reproduce: 1. Compile bonobo2 and at-spi (using fink, no fancy ./configure options) 2. Compile something that passes both -lbonobo-2 and -lspi to the linker, for example, dasher (3.2.15). Actual results: Step 2 gives issues warnings like: ld: warning multiple definitions of symbol _TC_Bonobo_StorageInfoFields_struct /sw/lib/libspi.dylib(Accessibility-common.o) definition of _TC_Bonobo_StorageInfoFields_struct /sw/lib/libbonobo-2.dylib(Bonobo-common.o) definition of _TC_Bonobo_StorageInfoFields_struct For many dozen _TC_Bonobo_* __ORBIT_skel_small_Bonobo_* _Bonobo_* and _POA_Bonobo_* symbols. Here's how the symbols are defined in the shared libs: % nm -m /sw/lib/libbonobo-2.dylib | grep Bonobo_StorageInfoFields 0003c88c (__DATA,__data) external _TC_Bonobo_StorageInfoFields_struct % nm -m /sw/lib/libspi.dylib | grep Bonobo_StorageInfoFields 0002d6c4 (__DATA,__const) external _TC_Bonobo_StorageInfoFields_struct Expected results: libspi shouldn't expose bonobo symbols, or if it does it shouldn't define them itself. Does this happen every time? Yes. According to 'otool -L', libspi.dylib links to libbonobo-2.dylib and libbonobo-2.la is listed in the dependency_libs of libspi.la, so linking against libspi will almost always be accompanied by linking to libbonobo2. Other information: Running OS X 10.3.9 compiled under XCode1.5 (gcc3.3)
This behavior is the same on OS X 10.4, XCode2.1. Here's a discussion I just had (in #fink@freenode)... 19:53 < msachs> I gather these are symbols that *are* supposed to be exported by bonobo. 19:54 < msachs> The problem here seems to be that libspi is being linked in such a way that it reexports those symbols. 19:59 < msachs> It's actually more interesting than that. 19:59 < msachs> Take a look at Accessibility-stubs.c in the at-spi source. 20:00 < msachs> It declares these stubs for a bunch of methods that just turn around and invoke them through ORBit. 20:00 < msachs> So there's a function in Accessibility-stubs.c, Bonobo_Stream_getInfo, which is a wrapper for calling that function through ORBit. 20:01 < msachs> Accessibility-stubs.c appears to be generated by configure. 20:03 < msachs> So they should be either stripping those symbols from the final library (in effect, making them private extern), or declaring them static, or giving them different names so they don't conflict with the real versions. 20:03 < msachs> Unless they *want* to override those functions. 20:04 < msachs> In which case they either need to have people link with them instead of bonobo, or they need to use DYLD_INSERT_LIBRARIES 20:04 < msachs> Or, I dunno, there's probably other funky tricks they can do. 20:04 < dmacks> Wow...wish I knew how libspi is supposed to function. 20:05 < msachs> Yeah. That's a key piece of information here, what the heck it's actually trying do. Whether those functions are for its internal use or whether it wants to override those calls in anything that links it. 20:06 < msachs> If they're going for an override, two-level namespaces may make their approach potentially work, but I doubt GNOME depends on two-level namespaces :) 20:07 < msachs> Yeah, it may be that the bug is "things shouldn't link both this and bonobo". 20:14 < msachs> Yes, I suspect some wackiness involving libtool is most likely the problem, if it were simply "these symbols should be static", it wouldn't work on anyone's platform.
Things must link to both libspi and bonobo AFAICT. The intention is not to override the bonobo stubs, but to reuse them. The code in question is autogenerated. Otherwise, I am waay out of my depth on this one. Perhaps MMeeks, who gave some assistance in this codespace before, can point the way?
OK - this is a simple one. It's all down to the IDL which is (bogusly) including Bonobo_Unknown.idl & co. in error. Instead we should just include Bonobo.idl in the top-level Accessibility.idl (or at worst include Bonobo.idl in each source file). That way we get the right pragma guards to stop this double emission. HTh.
As a quick hack, I did s/Bonobo_Unknown.idl/Bonobo.idl/ on idl/*.idl; 'nm libspi.dylib' now has all *_[Bb]onobo_* symbols flagged as "U" and dasher does not complain about multiple symvbol definitions.
The reason we explicitly do NOT include Bonobo.idl in at-spi is to limit out Bonobo IDL dependency to Bonobo_Unknown. We need to keep it that way somehow.
Well - then IIWY I would add an 'Accessible_Unknown.idl' that includes Bonobo_Unknown.idl - but with the right pragma logic around it cut/paste from Bonobo.idl. Either way it should be a trivial fix.
I don't know much about bonobo:( However, the first two tutorials I found on the web for writing bonobo components #include Bonobo.idl (not Bonobo_Unknown.idl) in their sample .idl files even though they make use of the Bonobo::Unknown namespace. See for example: http://www.djcbsoftware.nl/projecten/bonobo-gwizard/ http://www-128.ibm.com/developerworks/library/co-bnbo3.html
thanks Michael, I think your suggestion in comment #6 is the correct one. Or could we cut-and-paste the pragma logic into Accessibility.idl?
makes sense - I see no value in having the extra Bonobo_Unknown #includes all over the idl.
Created attachment 52189 [details] [review] Consolidate Bonobo_Unknown.h in idl/* Fixes comment 9 Not sure what the correct #pragma incantation is to wrap that new #include.
thanks dmacks. patch committed. I removed LoginHelper from Accessibility.idl, as it is a different sort of interface and belongs elsewhere (it's a service interface used/exported by assistive technology clients themselves, not applications). I also needed to reinstate the Bonobo_Unknown #include in LoginHelper.idl, but this shouldn't impact libspi itself (only libloginhelper). Please reopen if this was only a partial fix.
at-spi-1.7.8 still seems to have symbol leakage. Even while compiling libspi itself, I see the problem: gcc -dynamiclib -o .libs/libspi.0.10.9.dylib .libs/Accessibility-stubs.o .libs/Accessibility-skels.o .libs/Accessibility-common.o .libs/accessible.o .libs/action.o .libs/application.o .libs/base.o .libs/component.o .libs/document.o .libs/editabletext.o .libs/hyperlink.o .libs/hypertext.o .libs/image.o .libs/devicelistener.o .libs/relation.o .libs/remoteobject.o .libs/selection.o .libs/streamablecontent.o .libs/stateset.o .libs/table.o .libs/text.o .libs/util.o .libs/value.o .libs/listener.o .libs/eventlistener.o -L/sw/lib -L/usr/X11R6/lib /sw/lib/libbonobo-2.dylib /sw/lib/libORBitCosNaming-2.dylib /sw/lib/libpopt.dylib /sw/lib/libbonobo-activation.dylib /sw/lib/libORBit-2.dylib /sw/lib/libgthread-2.0.dylib /sw/lib/libgailutil.dylib /usr/X11R6/lib/libXrandr.dylib /usr/X11R6/lib/libXext.dylib /usr/X11R6/lib/libXcursor.dylib /usr/X11R6/lib/libXft.dylib /usr/X11R6/lib/libXrender.dylib /usr/X11R6/lib/libX11.dylib /usr/X11R6/lib/libfontconfig.dylib /usr/X11R6/lib/libfreetype.dylib /sw/lib/libgnomecanvas-2.dylib /sw/lib/libart_lgpl_2.dylib /sw/lib/libgtk-x11-2.0.dylib /sw/lib/libgdk-x11-2.0.dylib -lXrandr -lXinerama -lXext -lXcursor /sw/lib/libatk-1.0.dylib /sw/lib/libgdk_pixbuf-2.0.dylib /sw/lib/libpangoxft-1.0.dylib -lXft -lXrender /sw/lib/libpangox-1.0.dylib /sw/lib/libpangoft2-1.0.dylib -lfontconfig -lfreetype /sw/lib/libpango-1.0.dylib -lm /sw/lib/libgobject-2.0.dylib /sw/lib/libgmodule-2.0.dylib /sw/lib/libglib-2.0.dylib /sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lXtst -lSM -lICE -lX11 -install_name /sw/lib/libspi.0.dylib -Wl,-compatibility_version -Wl,11 -Wl,-current_version -Wl,11.9 ld: warning multiple definitions of symbol _POA_Bonobo_Storage__fini .libs/Accessibility-skels.o definition of _POA_Bonobo_Storage__fini in section (__TEXT,__text) /sw/lib/libbonobo-2.dylib(Bonobo-skels.o) definition of _POA_Bonobo_Storage__fini [followed by 3 other _POA_* and 50-100 other duplicate symbols between the local .o collection and various .dylib being linked in.
moving this to bonobo, as the remaining problem seems to be there. If the problem is in the at-spi IDL somehow, or can be avoided there, please provide a patch and reassign. Otherwise please keep in bonobo unless you can explain what the at-spi IDL is doing wrong. (Using bonobo.idl instead of Bonobo_Unknown.idl in AT-SPI is not an option IMO, since we want to contain the dependencies more tightly)
ok - this is in fact an at-spi bug; but it's workaround is not obvious :-) Ultimately, including Bonobo.idl is the correct thing to do - and while pulling in a ton of Bonobo stuff - that should generate no extra code; the current situation is: $ grep Bonobo Accessibility* 1811 If you use a #include <Bonobo.idl> - outside the pragmas, you get: $ grep Bonobo Accessibility* 379 A substantial reduction ;-) so - really, it's far better to include Bonobo.idl in it's entirety IMHO. Failing that you want to add the (grotesque): #ifdef __ORBIT_IDL__ %{ #pragma include_defs bonobo/Bonobo.h %} #pragma inhibit push #endif #include <Bonobo_Unknown.idl> #ifdef __ORBIT_IDL__ #pragma inhibit pop #endif instead of the plain Bonobo_Unknown.idl include. OTOH - we use more than Bonobo_Unknown - we use Bonobo_Stream.idl for Accessibility_StreamableContent.idl [ not certain that anyone has ever implemented that though ;-]. HTH.
Created attachment 69179 [details] [review] patch to avoid duplicate linking, see comment #14
There is a suspicion that this change may have triggered a build problem in some configurations - see comment #8 to bug 346456: http://bugzilla.gnome.org/show_bug.cgi?id=346456#c8
I reverted http://bugzilla.gnome.org/attachment.cgi?id=69179 ("patch to avoid duplicate linking, see comment #14"), and it could build again; I re-added the patch, and it failed again.
OK, I'll revert the patch now. Seems we need a different solution.
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
I'm going to go ahead and close this because it concerns a very old version. Feel free to open a new bug if the problem persists.