[Mono-list] Mono embedding issue

[Andreas Färber]

Hi Robert,

>>>> When embedding Mono 1.1.17.1 on OS X i386, I get an assertion  
>>>> failure
>>>> in mono_jit_init:
>>>> ** ERROR **: file threads.c: line 420 (mono_thread_attach):  
>>>> assertion
>>>> failed: (thread_handle)
>>>> aborting...
>>> This basically means that io-layer's GetCurrentThread returned
>>> NULL, which is completely nonsense because it always returns
>>> a constant value != NULL.
>>>
>>> I suppose MacOS has its own GetCurrentThread function which gets
>>> linked and called instead Mono's:
>>>
>>> http://bugzilla.ximian.com/show_bug.cgi?id=77324
>>
>> I already read that bug report. It refers to _GetCurrentProcess as
>> opposed to GetCurrentThread.
>
> Like GetCurrentProcess, GetCurrentThread is actually a Carbon  
> function:
>
> http://developer.apple.com/documentation/Carbon/Reference/ 
> Process_Manager/Reference/reference.html#//apple_ref/c/func/ 
> GetCurrentProcess
> http://developer.apple.com/documentation/Carbon/Reference/ 
> Thread_Manager/Reference/reference.html#//apple_ref/c/func/ 
> GetCurrentThread

I don't doubt that, as they don't sound like Cocoa functions.

> The proof by induction about why GetCurrentThread could fail as well,
> is left as an exercise for the reader :-)

Bad luck you mentioned this to a student doing lots of proofs by  
induction in his lectures... ;-) Proof by induction is only valid on  
an inductive set, which are defined to include the element 1 and for  
each element a an element a+1 ... I don't see how this would apply to  
symbolic export names which are more like |F2^n. Anyway, this depends  
highly on the precondition of whether the underlying linker emits  
warnings for each conflicting symbol or only for one. In the latter  
case it is possible. ;-)
With dozens of warnings emitted by Xcode at times I figured I should  
get a complete list of conflicting symbols just as in the case of  
missing glibconfig.h include file etc. Might've been wrong there.

> As suggested by bug #77324 (2006-03-10 16:38), you could try to
> reference the Mono framework before Carbon:
>
> 	gcc  foo.c -framework Mono -framework Carbon -o ...
>
>

I don't reference Carbon directly at all, I've added an explicit - 
framework Mono flag before -framework Foundation and reordered the  
frameworks, no change.

If it were a question of link order, then shouldn't it fail on ppc, too?

Anyway, I can't recompile my host application, which might or might  
not be using certain Carbon functions before loading my code  
dynamically... (which as a Universal binary it should do consistently  
on both platforms, no?)

Is the -undefined dynamic_lookup the problem, can it be replaced by  
something better? I needed it to get past the _environ symbol error I  
mentioned earlier.

Andreas