[Mono-devel-list] Static linking in mono beta2 breaks glib/gthread stuff

[Steven Brown]

In C# with DllImport, I'm trying to call gthread-2.0's g_thread_init, 
which in turn calls glib-2.0's g_messages_init, but since it's 
statically linked into mono in beta2, it seems to resolve to mono's 
internal copy.  But then when I call a glib-2.0 function directly, it's 
apparently a different instance than the internal copy, and explodes due 
to not having been initialized!

At least that's what seems to be happening; it's been a rather 
complicated one to debug. :)  This is a much worse situation than in 
beta1, where g_thread_init would have already been called by the 
runtime, but glib would at least work.

In the attached example, g_log_set_handler will throw a null reference 
exception on beta2 due to g_messages_lock being null, as it was never 
constructed by g_messages_init (the init call from gthread-2.0 -> 
glib-2.0 went to the wrong library instance it seems).  On beta1, the 
g_thread_init will give you a "GThread system may only be initialized 
once." due to mono starting it, but if commented out, g_log_set_handler 
will work.

It seems like beta2's static linking and dynamically loaded libraries 
just don't mix.  Is this just a bug that needs fixed, or is there a way 
I could code around it?  It's causing all sorts of failures with glib in 
SharpWT.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Test.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040607/2ebc09c2/attachment.pl