Re: Plugin RFC

From: J.M. Maurer <>
Date: Sat Apr 12 2008 - 00:16:46 CEST

On Fri, 2008-04-11 at 13:52 -0400, Dominic Lachowicz wrote:
> > > Another benefit of this *may* be that we won't run into those "plugin
> > > conflict" problems on Windows, where we can't load both plugin A and
> > > plugin B at the same time. Again, this is speculation.
> >
> > I'd rather see the issue properly analyzed, instead of "hoping it gets
> > away after some random changes".
> That's not what I meant, and I apologize for the confusion.
> With the "statically link plugins" feature we now have, it's possible
> to statically link in all plugins to the executable. Now, if 2 or more
> of the static "plugins" share symbols (which is why they fail to load
> at runtime), AbiWord.exe will fail to link. The linker will report
> which symbols are multiply defined and in which files those symbols
> are defined. It's not a random change, nor is the fix a "hope" - you
> need to do something in order to fix the problem. The benefit is that
> the linker will tell you where you screwed up.
> For example, Rob just turned this on and found an issue with
> "CreateChildProcess" being defined in both the Gimp and the Paint
> plugins. I'm hopeful that we'll uncover more of this and resolve the
> "can't load plugin X with plugin Y" issues.

For the record: dom and I built some plugins that only exported the 3
'plugin' symbols that every plugin needs to have. The load issue still
existed. Conclusion: the issue is _not_ a symbol clash related one.

Observation: say you have plugins A, B and C, the order in which plugins
are loaded matters. If you load A, B and C and C fails, then loading A,
C and then B will probably make B fail. At least in my tests.

Fun. I think the toolchain has some serious bugs.

Received on Sat Apr 12 00:18:07 2008

This archive was generated by hypermail 2.1.8 : Sat Apr 12 2008 - 00:18:07 CEST