gnunet-developers
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]