<div dir="ltr">Hi Olivier,<br><div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for the quick reply.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 27, 2013 at 11:34 AM, Olivier Crête <span dir="ltr"><<a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
> With GST_DEBUG set to '*:9', as Pidgin starts up I can see that some<br>
> plugins are loaded just fine and others fail. It looks like:<br>
</div>>       * fsmsnconference, fsrtcpfilter and fsrtpconference fail to load<br>
>       * fsrawconference, fsvideoanyrate load just fine<br>
<br>
The important ones for pidgin are: fsrtpconference, fsrtcpfilter, and<br>
fsvideoanyrate.<br>
<div><br>
> For "deployment" of the plugins I just copied the DLLs to C:\Users\cp<br>
> \.gstreamer-1.0, set GST_PLUGIN_PATH to point there, and copied other<br>
> dependent DLLs into the pidgin.exe directory. Using Dependency Walker<br>
> seems to show no missing dependencies. So I guess I wonder if anyone<br>
> has any thoughts on:<br>
</div>>       * What kinds of things would cause loading a plugin to fail?<br>
>       * Can you suggest any extra debugging steps I might try?<br>
>       * Do you see a pattern in terms of which plugins load and which<br>
<div>>         ones fail that might point me in the right direction?<br>
> I appreciate any help you can offer. Thanks!<br>
<br>
</div>My guess is that the Windows DLL loader is not happy, there must be some<br>
way to debug that ?<br>
<br>
Also, Depencency Walker will not give you all dependencies, as you also<br>
need some other gstreamer plugins, like the codecs, etc. You may want to<br>
just try with adding all of the gstreamer plugins, not just a subset.<br>
But you're not even getting there in this log.<br></blockquote>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.<br>
<br></div><div class="gmail_quote">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.<br><br><br></div><div class="gmail_quote">
Also thank you for your comments on <a href="https://bugs.freedesktop.org/show_bug.cgi?id=62793">https://bugs.freedesktop.org/show_bug.cgi?id=62793</a> - I'll definitely save myself some shm trouble by using:<br><pre class="" id="comment_text_1">
configure --with-transmitter-plugins=nice,rawudp,multicast </pre>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().<br>
<br>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.<br>
<br></div><div class="gmail_quote">Thanks again for your help!<br><br></div><div class="gmail_quote">-- Conrad<br></div></div></div></div>