[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] libgsf vs libextractor
From: |
Jody Goldberg |
Subject: |
Re: [GNUnet-developers] libgsf vs libextractor |
Date: |
Tue, 10 May 2005 00:28:58 -0400 |
User-agent: |
Mutt/1.5.9i |
On Thu, May 05, 2005 at 04:47:57PM -0500, Christian Grothoff wrote:
> Well, the bug fix is mostly a tricky approach to linking stuff, and I did
> send
> an E-mail to you about it way back when and got no reply.
Apologies I must have missed/spam-bucketed it.
> The primary problem is what happens if you load a plugin that links against
> libgsf with dlopen, unload it, and load it again. If you do that from an
> application that itself (!) links against glib, you're in trouble (since the
> types are loaded / registered twice with glib and that's not going over too
> well). The solution was to statically link libgsf against glib. Details are
> in the bugtracking system (http://gnunet.org/mantis/, look under closed bugs
> for libextractor).
yes, libgsf is not currently designed to be unloaded. It would be a
fairly trivial change though. We could look into offering a
void gsf_dynamic_init (GTypeModule *mod);
void gsf_dynamic_shutdown (GTypeModule *mod);
> I think there were also some minor problems with error handing in libgsf
> (given the right mal-formed streams), but you can probably find those by
> doing a diff (and ignoring me deleting lots of code that we did not need).
> We have since then switched version control systems, so I can't easily find
> those changes (if that is what you're interested in).
It's difficult to do that without knowing what version you forked
from.
PS
1) Could you correct the copyright assignments ?
2) You'll want to update your version of libgsf. 0.12.0 came
out today with several fixes for OLE2 meta data streams.