On Sunday 20 March 2005 22:17, Glenn L McGrath wrote: > Hi, > > There has been a niggling problem with the ole2 module of libextractor > for a while, it has been worked around within debian (1), but gentoo > still has problems with it (2), and i suspect it may cause problems to > others in the future. > > The problems relates to the ole2 module linking to glib and duplicate > symbols, i dont think i understand the precise nature of the problem > (which means you should be sceptical about my patch), but think i may > have a better solution than static linking to glib.
Well, not _precisely_. The problem is a fundamental problem with glib's type system and dynamic loading. It can only be observed if LE is linked against by a program that already uses glib (like, say, gnunet-gtk). The bug goes as follows: glib is loaded and initializes glib type system (so far so good) program loads LE; LE is _not_ aware of glib (since LE itself does not link against glib and does not require glib), so glib loads plugins using libltdl and _not_ using glib's plugin loader mechanism (which, btw, seems to suck anyway). Without the static linking of glib, the ole2 plugin links against the already loaded version of glib and registers its types with the glib typesystem (so far, so good). The plugin works just fine. Eventually, the app unloads the LE plugins. However, the glib type system does not have any provisions for the ole2 plugin to _unregister_ its types (unless loaded with the glib plugin mechanism, which we were not using, see above). So the type information sticks around in glib's static memory. Note that if glib was not used by the main application, the type information would _not_ stick around since glib itself would be unloaded (which also happens to the statically linked glib). Now, problems happen when the app re-loads the LE plugins. The ole2 plugin has to re-register its glib types -- however, types with the same names (! what an odd thing to do anyway !) have already been registered. glib refuses to re-register the types, the glib typesystem fails on the ole2 plugin, and it stops working (libgsf-1 used to crash, but we've made sure that the existing ole2 code doesn't do that). Anyway, the fix that upsets people is to statically link against glib (which, since the resulting library is still a _dynamic_ (plugin) library requires the static glib version to be relocatable, which is not typically the case on some distributions). The workaround would be perfect except for this problem with statically linking in a library into a dynamic library -- something that some people seem to take offense with. > The attached patch removes the gsf-* code in libextractor and simply > links to the shared libgsf-1 library. > > Advantages i see > - The glib linking problem is passed off to libgsf > - Libgsf may expand in the future to support more formats. > - less code to maintain/better code reuse Well, or more code to link against with more bugs. The LE version of the libgsf-1 code has had some bugfixes (to be less likely to crash when facing crazy inputs). > The only test i have done is libextractor's make check, which works > fine. Right, however, the problem cannot be observed just by using libextractor on any file. You need to link against LE from an application that dynamically links against glib and then loads-unloads-loads the LE plugins. > I dont have an ole2 file to test it with and dont know much about the > format, anyone know where i can get one ? Any M$ Office product generates those files. xls, doc, ppt are all OLE2 streams. > If this is a resonable solution i will do a better patch that cleans up > configure.ac as well. There are actually only two good solutions to the problem that could be done on the LE side of things: a) integrate (the portions of) glib that we're using (statically and explicitly) into the ole2 plugin's code so that we don't rely on the system having a relocatable, static version available to link against b) re-write the libgsf-1 code to _not require_ glib at all. This is possibly the easier path and of course much better since it would result in a much more compact system. The third solution is to shut long enough at the glib developers to fix their type system; however, since this would probably be a really major change this would probably happen at the same time where GNU hurt becomes the most commonly used OS on the planet, so we may not want to wait for that. And of course, gentoo could just provide a relocatable static version of glib to link against. That'd work, too. > Thanks > > Glenn > > > 1) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282342 > 2) http://bugs.gentoo.org/show_bug.cgi?id=79704 More details: http://gnunet.org/mantis/view.php?id=787 Christian _______________________________________________ GNUnet-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnunet-developers
