Windows executable fails to load fsrtpconference and other plugins

[Olivier Crête]

On Wed, 2013-03-27 at 14:09 -0600, Conrad Poelman wrote:
> 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'm really not a Windows person, so I have no idea how this stuff works.

> Also thank you for your comments on
> https://bugs.freedesktop.org/show_bug.cgi?id=62793 - 
> 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().

I can prepare a patch and then you can test if that helps.

> 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.

aMsn uses Farstream on Linux, Windows, Mac, but the last release still
uses GStreamer 0.10, and don't expect a new release as Microsoft are
shutting down the servers. For the basic functionality, you can try wit
the command line in examples/command-line


-- 
Olivier Crête
olivier.crete at collabora.com