[GNUnet-developers] Re: libextractor ole2 and libgsf

[Christian Grothoff]

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