** (process:25873): WARNING **: Failed to set operation type over, using a
passthrough op instead

** (process:25873): WARNING **: Failed to set operation type over, using a
passthrough op instead

This seems to indicate that the generated operations are not found (probably not even built) are you building from SVN trunk or from the 0.0.16 tarball, building from the 0.0.16 tarball will remove the need for a working ruby installation (but make it harder to track development).

--------

** (process:25873): WARNING **: pads_exist: Can't find sink property aux of nop
babl-format.c:425 babl_format()
        babl_format("B'aG'aR'aA u8"): not found
Attaching to process 25873.

This indicates that babl is unable to find it's extensions, I do not know enough
about how GEGL and babl are built and installed on mac to really make a guess about what is going wrong here you might want to make the environment variable BABL_PATH point to where the extensions for babl have gotten installed.

thank you for that information
i had modified some of the sources in order for my older system to build them as bundles using gnu libtool and load them natively as opposed to using dlcompat for dlfcn
i typo'd
works now

Probably worth noting that "loadable modules" and "linkable libraries" are two different things on OS X, something that the Makefiles do not understand. A lib that is intended to be dlopen()ed and not linked against by other binaries should be compiled with -bundle instead of-dynamiclib and the normal extension is .so or sometimes .bundle instead of .dylib. In particular IIRC, linker libraries (-dynamiclib) cannot be dlclose()ed on any OS X until the most recent version. Hand-coding all these flags and extensions is getting to be painful!

I ultimately accepted compilation using libtool for GEGL even though
build+install of the operations now has doubled in time. Build time for 
the plug-ins is less of an issue for babl though.

Does this means the following would make things be more correct on mac is the following modification to configure.ac? It could perhaps be even more useful to get the patch that was used to make it build using libtool and loading natively,
darwin not quite being like other unices is painful, it almost seems like the
decision of DOS to use backslashes instead of slashes to build paths.

Index: configure.ac
===================================================================
--- configure.ac        (revision 289)
+++ configure.ac        (working copy)
@@ -162,8 +162,8 @@
 AC_MSG_CHECKING([for some Win32 platform])
 case "$target_or_host" in 
   *-*-darwin*)                 # darwin
-    shrext=.dylib
-    dynamiclib=-dynamiclib
+    shrext=.so
+    dynamiclib=-bundle
     ;;
   *-*-mingw* | *-*-cygwin*)    # windows
     shrext=.dll

If you're libtoolized, then *everything* is done for you, you don't have to special-case or "if $some_os then $some_odd_thing" anywhere. Will look at SVN version and see how to generalize it later tonite.

extensions/ doesn't look libtoolized in trunk on svn.gnome...is there somewhere else that this is being developed? Assuming libtool, dlopen()able things are declared as "-module", and libtool knows the correct linker flag and extension for the target platform. Likewise, linking against a library is just using the .la extension, and libtool knows the correct extension and path into the .libs/ subdir for passing to the linker. So the only place anything platform-specific is needed is the loadable-module extension, for in the strcmp() when reads the extensions directory. There's a way to ask libtool what it is, can't remember off-hand.

GEGL has been libtoolized, babl has not I was referring to the comment #2 in this thread.

(In reply to comment #4)
that's what i did with configure.ac, then i completely gutted out extensions/Makefile.am and replaced it
as for the native loading, my system is older and what i've read says that the method i'm using is depreciated on newer systems, so you'd want to take it with a grain of salt (i'm not good at this)

Created attachment 106495 [details]
libtoolized extensions/Makefile.am

Created attachment 106496 [details] [review]
crudely patched babl-extension.c

That extensions/Makefile.am looks pretty close to the one I'm testing for Fink. Only functional difference is that I have:

libbabl=$(top_builddir)/babl/libbabl-$(BABL_API_VERSION).la

for *all* platforms, not just win32 (which is a weakness in the existing Makefile.am as well), because the plugins all use symbols from that lib. By either linking the lib directly or via -bundle-loader, all symbols are defined at link-time, which makes runtime loading smoother.

For simplicity, one can have a unified AM_LDFLAGS (akin to AM_CFLAGS, which should actually be AM_CPPFLAGS or INCLUDES not AM_CFLAGS) instead of specific *_la_LDFLAGS for each plugin.

(In reply to comment #11)
to be honest, after configure, i do uncomment the lines to add -no-undefined and whatever project's library that's just been built, with babl et al

Created attachment 106952 [details] [review]
Fix search-pattern for plugins

If the extensions are built by libtool, don't need to know the specific extension for shared libraries. If the extensions are built by libtool as -module, just ask libtool what extension will be used instead of guessing based on platform