GNOME Bugzilla – Bug 555978
[ladspa] no elements exposed/found on Cygwin
Last modified: 2009-04-17 11:00:34 UTC
I have got LADSPA (ladspa-sdk, ladspa-cmt, and swh-plugins) working on Cygwin, but the GStreamer ladspa plugin is not registering any elements. The problem appears to be that the gstladspa plugin is a module; a program made with the same code appears to work as expected. I'm attaching a test case and results to help figure this out.
Created attachment 120419 [details] Test case This patch adds some printf()s around the callback, and adds a main.c which will be used to make a program out of the module.
Created attachment 120420 [details] results from plugin After patching, build and install the ladspa plugin and run "gst-inspect ladspa"; these are the results on my machine.
Created attachment 120421 [details] results from program Now make the test case into a program: make main.o gcc -o test.exe main.o .libs/*.o `pkg-config --libs gstreamer-0.10` ./test Here are the results from my machine.
Created attachment 120422 [details] results from listplugins For good measure, this is the output of listplugins (from ladspa-sdk) on my machine.
Have you perhaps installed the ladspa-plugins after the gstreamer one? Does it help to remove the registry cache in $HOME/.gstreamer-0.10/ and re-run gst-inspect.
> Does it help to remove the registry cache in $HOME/.gstreamer-0.10/ and > re-run gst-inspect. No, tried that already.
can you please attach a log like this after the registry has been reset GST_DEBUG="ladspa*:4" GST_DEBUG_NO_COLOR=1 gst-inspect ladspa 2>debug.log
The log is empty.
GST_DEBUG="*:4" GST_DEBUG_NO_COLOR=1 gst-inspect 2>debug.log if its still empty, your gstreamer has logging disabled. It would be quite hard to figure out anything then. For developers its a good idea to have it enabled.
Created attachment 121185 [details] full debug log > GST_DEBUG="*:4" GST_DEBUG_NO_COLOR=1 gst-inspect 2>debug.log That's anything but empty; compressing due to bugzilla attachment size limit.
GST_INIT /usr/src/ports/media/gstreamer0.10/gstreamer010-0.10.21-1/src/gstreamer-0.10.21/gst/gst.c:671:scan_and_update_registry: Validating registry cache: /home/Yaakov/.gstreamer-0.10/registry.i686.bin ... GST_INIT /usr/src/ports/media/gstreamer0.10/gstreamer010-0.10.21-1/src/gstreamer-0.10.21/gst/gst.c:738:scan_and_update_registry: Registry cache has not changed I was asking for such a log, which out having a registry. The ladspa plugin is registered. But I would need to see a log where the cache is rebuild, to see why the ladspa plugin does not register any elements.
Created attachment 121208 [details] full debug log (with registry deleted)
pcLADSPAPath = g_strdup_printf ("%s:/usr/lib/ladspa:/usr/local/lib/ladspa", getenv ("LADSPA_PATH")); Have you exported LADSPA_PATH? Is there a standart location where those are installed under windows?
Cygwin != Windows. Cygwin uses a *NIX file hierarchy; the plugins are in /usr/lib/ladspa, and LADSPA_PATH is exported as such.
Sorry, got it. The scanning happens in ext/ladspa/search.c. Could ypu try adding some printfs there or start gst-inspect (after removing the resgistry) in gdb and set a break point to LADSPAPluginSearch ?
Yaakov: ping?
Created attachment 129771 [details] [review] core configure.ac patch Thanks for the nudge. I took a fresh look at this and I finally figured this out. Since the loading of LADSPA plugins is left to the client code, and the base LADSPA plugins are not built with libtool, the Cygwin Ports ladspa-* packages use the .so extension as on other platforms. The problem here was that GStreamer was ignoring the LADSPA plugins because they didn't match the .dll extension usually used on Cygwin (as defined by G_MODULE_SUFFIX). I'm attaching a patch for core's configure.ac which defines GST_EXTRA_MODULE_SUFFIX to fix this issue, and fixes some other platform-specific-settings issues (Cygwin *is* a POSIXy platform, and while we have fork(), it's a bit safer to avoid it if the option exists).
While this patch is probably correct this doesn't explain this bug as the ladspa plugin simply tries to dlopen() all files inside the ladspa plugin directories, no matter what extension they have. Do you have an idea why this patch fixes this bug for you?
Created attachment 129813 [details] [review] Cygwin unsafe fork patch You're right; it looks like I stumbled upon the real solution when I changed the other platform-specific settings. After testing each of the changes in the patch individually, it turns out the GST_EXTRA_MODULE_SUFFIX isn't the issue after all. For some reason that I don't perfectly understand yet, if the registry is rebuilt from a fork(), the ladspa plugins either aren't properly loaded. If the registry fork is disabled, then they load just fine. Since anyway using fork() on Cygwin can be problematic under certain circumstances, all we need to do is define GST_HAVE_UNSAFE_FORK. Patch attached.
The problem might be that a non-forking registry will already have the ladspa plugins loaded, tries to load them a second time when the gstreamer ladspa plugin is initialized and then things go wrong... but this is just a guess ;)
I have rewritten the plugin loading for ladspa totally. It now uses glibs gmodule and it also G_MODULE_BIND_LOCAL, which might help. Could you retry with gst-plugins-bad from git?
(In reply to comment #21) > I have rewritten the plugin loading for ladspa totally. It now uses glibs > gmodule and it also G_MODULE_BIND_LOCAL, which might help. Could you retry with > gst-plugins-bad from git? Rebuilt core .22 without the UNSAFE_FORK define and tried -bad from git. Results are the same: ladspa elements are only found if forking is disabled. FYI, same happens w/o G_MODULE_BIND_LOCAL. OTOH I see no regressions, and the lrdf support is a plus.
(In reply to comment #22) > (In reply to comment #21) > > I have rewritten the plugin loading for ladspa totally. It now uses glibs > > gmodule and it also G_MODULE_BIND_LOCAL, which might help. Could you retry with > > gst-plugins-bad from git? > > Rebuilt core .22 without the UNSAFE_FORK define and tried -bad from git. > Results are the same: ladspa elements are only found if forking is disabled. > FYI, same happens w/o G_MODULE_BIND_LOCAL. > > OTOH I see no regressions, and the lrdf support is a plus. > There is now a bit more logging. Could you reattach a log. What I wonder is if in ladspa_plugin_directory_search() it fails to load the plugins. Maybe you can even add one or two more log-statements there. Thanks for your patience with this.
I think I may have made some progress in figuring this out. Having installed a few more LADSPA plugins since I opened this bug, I see now that different plugins behave differently when the registry is scanned in a fork(): 1) vlevel: actually registers! 2) blop: segfaults (caught by GStreamer segtrap) 3) sdk, cmt, caps, swh-plugins, vcf: do not register. All of the above register when fork() is disabled. I'm not sure about blop yet, but AFAICS the notable difference between vlevel and the others is that vlevel uses a standard C++ ctor/dtor while the others use __attribute__((ctor/dtor)) _init()/_fini(). Could that make a difference in terms of how they are loaded?
Created attachment 130353 [details] [review] revised Cygwin patch Looking around in gst/gst.c, I found another Windows-ism applied to Cygwin. This patch supersedes the last two by adding a fix for that as well. Let me clarify that this patch should be applied *regardless* of any changes to the ladspa plugin. Cygwin's fork(), while it generally works, is prone to issues which would better be avoided if the option exists, as it does here.
I wonder whether this should go into the prereleases? Marking as blocker for now.
Is it intentional to remove the "AC_DEFINE_UNQUOTED(HAVE_WIN32, 1, [Defined if compiling for Windows])" line from the cygwin case in configure.ac?
Yes. The comment explaining HAVE_WIN32 should make it clear exactly why it doesn't apply to Cygwin.
Coolo. Thanks!
commit 4ce04783b37fd25ffc298b8e642f73ba275a2830 Author: Yaakov Selkowitz <yselkowitz@users.sourceforge.net> Date: Fri Apr 17 11:44:11 2009 +0100 configure.ac: fork() during registry scanning is unsafe on Cygwin Fixes #555978. commit eacfe25cf9d503fd8ca7ec16ca2918551cdd3d83 Author: Yaakov Selkowitz <yselkowitz@users.sourceforge.net> Date: Fri Apr 17 11:39:59 2009 +0100 gst_init: relocatability is unnecessary on Cygwin See #555978.