Hi, > Maybe it's just gimp-perl then. Maybe it's the fact that gimp-perl simply > relies on all symbols, while gimp-print probably only relies on the most > common (&small) subset. In that case, most probably only gimp-perl is hurt... > Which might also be the only plug-in where the community has considerable > need to be convinced that a new version of some tool is as stable as the old > one (because people's income depends on working servers) before they switch. > > Anyway, I *did* switch to the new API before writing my lament. I wrote > that mail because I *do* think such an under-the-hood-change deep *within* > the feature freeze is highly unconventional. Marc, believe me or not, but there was no great API change. The symbols gimp-perl used to use have been mapped to the new API until recently by defines and typedefs in gimpcompat.h and gimpenums.h. Now these defines are disabled by default and you can turn them back on with a small change to your Makefile. The number of symbols you use from that set should be totally irrelevant. Maybe your problems to get gimp-perl going with GIMP_ENABLE_COMPAT_CRUFT defined were related to the fact that gimp-perl seems to prefer to use installed libgimp header files over the current ones in the source tree. Salut, Sven
