Spawned from Bug #616553, which is aimed at determining the location of the runtime libpython...

gst-python-0.10.18/plugin/gstpythonplugin.c plugin_init() has:

>  GST_LOG ("Checking to see if libpython is already loaded");
>  g_module_symbol (g_module_open (NULL, G_MODULE_BIND_LOCAL), "Py_None",
>      &has_python);
>  if (has_python) {
>    GST_LOG ("libpython is already loaded");
>  } else {
>    GST_LOG ("loading libpython");
>    libpython =
>        g_module_open (PY_LIB_LOC "/libpython" PYTHON_VERSION "."
>        G_MODULE_SUFFIX, 0);
>    if (!libpython) {
>      GST_WARNING ("Couldn't g_module_open libpython. Reason: %s",
>          g_module_error ());
>      return FALSE;
>    }
>  }

That makes the platform assumption that the filename extension used for loadable modules is the same as that used for dyld libraries. Not true on OS X. For me, a shared library is libFOO.dylib whereas things built using the libtool "-module" flag (which is what G_MODULE_SUFFIX is) have the extension ".so". And if python were built as a framework, it may not have an extension at all.

No problem on linux and similar platforms: both are .so. But just luck or (robust build tools:) that I guess plugin_init is always called from within a runtime situation that already has libpython loaded (modules linked against it, or parent-process is linked against it).

Minor user-experience//debugging improvement for when things go wrong here: have the GST_WARNING include the actual filename trying to access rather than just "libpython"?

I don't know how to interrogate libtool or other parts of the build toolchain to determine the proper extension here. Maybe there's a variable available in lt's autoconf bits.