There is a slight problem with the code in HEAD GIMP, that manifests itself at least on Windows, but probably also on other non-ELF platforms (AIX, others?).

On Windows, when building shared libraries (DLLs), one must use the -no-undefined switch to libtool. I.e. there can be no references that are resolved only at run-time when the shared library is attached to a process. All external references must be to a known "module" (either another DLL or the EXE itself that will use the DLL).

In libgimpwidgets, the problematic functions are gimp_palette_get_foreground(), gimp_palette_get_background(), gimp_standard_help_func(), etc. On ELF systems, I assume it works so that when libgimpwidgets is used by a plug-in, those entries are resolved from the shared libgimp already attached to the process. When libgimpwidgets is used by the gimp application, the entries are resolved from the application itself.

Now, for libgimpwidgets, Hans Breuer already has implemented a workaround (the libgimp-glue.c file), containing proxy entries for said functions, which call a helper function that effectively does the dynamic linking "by hand". But this file is Windows-specific.

However, similar style of programming has also recently been introduced in libgimptool, and maybe elsewhere (I have just recently started looking at HEAD, only got this far yet). Using a similar glue file as libgimp-glue.c, and keeping it up-to-date, adding proxy functions as needed, does not seem like the Right Way to handle this.

Before this goes out of hand, could we please agree to stop assuming ELF features? Maybe even use -no-undefined on all platforms?

To handle the dynamic linking either to libgimp or the gimp exe, why not use the features that GModule provides? g_module_symbol() on the result from g_module_open (NULL, G_MODULE_BIND_LAZY) searches the currently loaded shared libraries, *and* the application. Works also on Windows.

--tml