[Bug 44331] Gabble plugin API symbols should be factored out to a separate library

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44331

--- Comment #6 from Olli Salli <ollisal at gmail.com> 2012-01-04 13:35:53 PST ---
Mmm, it looks like this alone doesn't suffice to make Ytstenut (and I believe
other plugins) work on Windows.

Siraj updated the branch to have a proof of concept setup where the plugins
library has all of the symbols in the gabble convenience library, and both the
gabble executable and the plugins link to the plugins library. However, it
linked correctly, but he hit the following assert, which isn't hit on Linux:

g_return_val_if_fail (g_simple_async_result_is_valid (result,
    G_OBJECT (plugin), gabble_plugin_create_sidecar), NULL);

The corresponding GAsyncResult is created in the ytstenut plugin for gabble
like this (removed SALUT ifdefs for clarity):

GSimpleAsyncResult *result = g_simple_async_result_new (G_OBJECT (plugin),
    callback, user_data,
    /* sic: all plugins share {salut,gabble}_plugin_create_sidecar_finish() so
we
     * need to use the same source tag.
     */
      gabble_plugin_create_sidecar
    );

gdb shows that g_simple_async_result_is_valid returns false because... tada,
the source tag is not the same.

I think this is because, even though both pull the actual function
implementation from the same plugins .dll, in Windows function pointers to DLL
functions actually point to import stub functions which are like:

int func_from_dll(double param) {
  static int (*real_func) (double) = NULL;
  if (!real_func) ptr = GetProcAddress(... "func_from_dll");
  return (*ptr)(param);
}

A bunch of these are linked in from a "DLL import library", which is a static
library which is produced along with the DLL when linking one.

A similar construct in Linux is the ELF indirection table, but it exists only
in final executables, not all intermediate DLLs etc, and is produced by the
linker when creating an executable. Thus, there's only one copy of these
functions. In short, the runtime linking in linux does a bit more work, but as
a reward global symbols are actually really global with just one definition 

But in Windows, these are pulled in from the small static import libs already
at link time. As such, there's a separate copy of these small functions for
each library linking to external DLLs in a running executable... and hence
function pointers to them have different values depending on where you refer to
them :o.

Thus, the ytstenut plugin has no way to create the async result in such a way
that its source tag would be correct when it is checked in gabble (plugin .dll
fills it with address to its own stub function copy, gabble verifies it against
address to the copy in the main .exe).

So I was wondering, is this a fundamental incompatibility of GSimpleAsyncResult
with Windows .dlls, or are we just using it wrong? Anybody has a lead on
somebody who would be a guru in GIO and Windows?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.