Windows executable fails to load fsrtpconference and other plugins

[Conrad Poelman]

Hi Olivier,

Thanks for the quick reply.

On Wed, Mar 27, 2013 at 11:34 AM, Olivier Crête <olivier.crete at collabora.com
> wrote:

> > With GST_DEBUG set to '*:9', as Pidgin starts up I can see that some
> > plugins are loaded just fine and others fail. It looks like:
> >       * fsmsnconference, fsrtcpfilter and fsrtpconference fail to load
> >       * fsrawconference, fsvideoanyrate load just fine
>
> The important ones for pidgin are: fsrtpconference, fsrtcpfilter, and
> fsvideoanyrate.
>
> > For "deployment" of the plugins I just copied the DLLs to C:\Users\cp
> > \.gstreamer-1.0, set GST_PLUGIN_PATH to point there, and copied other
> > dependent DLLs into the pidgin.exe directory. Using Dependency Walker
> > seems to show no missing dependencies. So I guess I wonder if anyone
> > has any thoughts on:
> >       * What kinds of things would cause loading a plugin to fail?
> >       * Can you suggest any extra debugging steps I might try?
> >       * Do you see a pattern in terms of which plugins load and which
> >         ones fail that might point me in the right direction?
> > I appreciate any help you can offer. Thanks!
>
> My guess is that the Windows DLL loader is not happy, there must be some
> way to debug that ?
>
> Also, Depencency Walker will not give you all dependencies, as you also
> need some other gstreamer plugins, like the codecs, etc. You may want to
> just try with adding all of the gstreamer plugins, not just a subset.
> But you're not even getting there in this log.
>
Yes, I and probably many others have a longstanding hatred of the Windows
LoadLibrary interface. A module can fail to load for a dozen different
reasons and Windows just reports error 126 - "The module could not be
found." Missing dependent DLLs are the most common problem, but also if a
static DLL initialization of the library or any of its dependencies fails
(e.g. I believe something analogous to throwing a C++ exception in a static
constructor?), Windows refuses to load the DLL and reports the same error.

I guess I'll just try a fully clean build, copying all gstreamer plugins to
~/.gstreamer-1.0, etc. If you think of any other ideas please let me know.


Also thank you for your comments on
https://bugs.freedesktop.org/show_bug.cgi?id=62793 - I'll definitely save
myself some shm trouble by using:

configure --with-transmitter-plugins=nice,rawudp,multicast

As you can probably tell I have no experience with Glib, and I should have
thought to check it for cross-platform abstractions before introducing
#ifdefs. If you prefer to make these changes yourself that's fine, but if
you'd like me to, I'll switch to G_GINT64_FORMAT/G_GUINT64_FORMAT and can
take a look at using g_inet_address_new_from_string().

Do you have any suggestions of how I can test farstream out on Windows?
Eventually Pidgin will be my testbed, but until that works, if I implement
g_inet_address_new_from_string() I'm wondering how to test it.

Thanks again for your help!

-- Conrad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/farstream-devel/attachments/20130327/8d9bb86b/attachment.html>