Hans Breuer <hans@xxxxxxxxxx> writes: > At 04:13 05.02.01 +0000, Nick Lamb wrote: > >On Mon, Feb 05, 2001 at 02:26:23AM +0100, Hans Breuer wrote: > >> The windoze version of gimpwidgefts can't include two symbols for > >> different implementation of the same function. There is only one > >> version of the dll in memory, even if loaded by another process. > >> The code is shared across process boundaries while the data is > >> not. > > > >Try making two copies of the DLLs with different filenames, and link > >plug-ins to one while gimp.exe links the other, that should fix it > >right? > > > Yepp, but I was serching for a better way. Most of the stuff in gimpwidgets > appears to be useful for other apps as well, but the whole lib won't be > reusable, if there is a Gimp dependency. (I especially like the simplified > method to construct option menus.) The option menu stuff is so gimp specific that it is in libgimpui (not libgimpwidgets) which may only be linked from gimp plug-ins anyway. > Maybe the widgets, which are using Gimp internals should be split from > gimpwidgets and linked into gimpui.dll (for plug-ins) or gimp.exe ? Almost done :) The only ugly dependency from libgimpwidgets into libgimp will be the GimpUnit stuff. The plan is to hack a very small "libgimpglue" library which will swallow this dependency. To use libgimpwidgets in an other application, it will be enough to strip the PDB dependency from the libgimpglue source code and you're done (of course there will be no user-defined units any more unless the "other" application provides an implementation of this functionality). Coming back to your real problem: before we started to restructure the libgimp stuff, those widgets were linked statically into the GIMP, so it's probably the best idea to continue to do so for Win32. Maybe you can do some Makefile voodoo and send a patch ? ciao, --Mitch
