[Mono-list] io-layer naming issues on OSX.

Andreas Färber andreas.faerber at web.de
Tue Oct 17 05:37:11 EDT 2006


Am 17.10.2006 um 10:01 schrieb Robert Jordan:

> The problem is not those duplicate WAPI symbols.
> It's the "export char **environ" declaration in metadate/icall.c,
> which prevents libmono from being loaded from inside another
> dll. This has forced people to link using the fuzzy Mac OS X LD
> option '-undefined dynamic_lookup'.
> This option leads to a world of pain, because even module global
> symbols defined in static libraries (like libwapi) are dynamically
> resolved. libmono was ending up calling Carbon's GetCurrentThread
> due to this option.
> Until the runtime gets fixed (I'll provide a patch), the
> workaround is to define and initialize "environ" from
> within the dll that links libmono.

Unfortunately I cannot confirm this.

> Do *not* link with
> '-undefined dynamic_lookup' any more:
> #include <mono/jit/jit.h>
> #include <crt_externs.h>
> char **environ = NULL;
> void foo ()
> {
> 	environ = *_NSGetEnviron ();
>      	mono_jit_init ("FooDomain");
> }

Using official Mono 1.1.18, removing the -undefined dynamic_lookup (I  
did ask about it in my original message!) does not lead to any change:


** ERROR **: file threads.c: line 420 (mono_thread_attach): assertion  
failed: (thread_handle)

Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.


(where the "mono_jit_init" line is a printf output just before  
mono_jit_init, on return there would be another output)

Could it be the combination of both renaming the symbols *and* fixing  
the dynamic_lookup workaround?


P.S. On a related topic: When I recently moved from to  
1.1.18 I had to recompile my native code because it is somehow being  
hardcoded to the current version - do you know a way to make this  
work independent of the installed Mono framework version?

More information about the Mono-list mailing list