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.


Gimp-developer mailing list

Reply via email to