[Mono-list] io-layer naming issues on OSX.
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
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 126.96.36.199 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