[Mono-list] Mono embedding issue
andreas.faerber at web.de
Tue Oct 10 11:18:15 EDT 2006
>>>> When embedding Mono 184.108.40.206 on OS X i386, I get an assertion
>>>> in mono_jit_init:
>>>> ** ERROR **: file threads.c: line 420 (mono_thread_attach):
>>>> failed: (thread_handle)
>>> 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:
>> I already read that bug report. It refers to _GetCurrentProcess as
>> opposed to GetCurrentThread.
> Like GetCurrentProcess, GetCurrentThread is actually a Carbon
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
More information about the Mono-list