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

Robert Jordan robertj at gmx.net
Tue Oct 17 04:01:19 EDT 2006


Miguel de Icaza wrote:
> Hello,
>>> I'd rather limit any renaming to the specific platform that  
>>> requires it.
>>> In bug 77324 it's mentioned that we don't use a linker script on  
>>> macosx;
>>> that should be the first part to be fixed imho.
>> Apart from not yet getting Mono to compile for any local experiments  
>> whatsoever, I do know C but have no idea what a linker script is  
>> supposed to be... Obviously some part of the existing auto* jungle  
>> already leads to a linker being invoked. Sorry for my ignorance ...  
>> so would that be an additional shell script or simply Makefile  
>> changes or what? What does "we don't use a linker script on macosx"  
>> mean in cleartext?
> I would probably go with some minimized set of defines myself.
> The linker script is a way of controlling what the linker does, but
> given the little knowledge among most of us about how to do this, its
> implications and the need to maintain it on the long term, it seems like
> the kind of hack that we might want to stay away from.
>> In Visual C++ on Windows I used to have explicit export definition  
>> files for DLLs listing the symbols to be exported - is there no such  
>> easy way on other platforms to limit the exported symbols to those  
>> potentially invoked by developers embedding Mono?
> The linker script would help here, but someone has to figure it out and
> maintain it.

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. 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");


More information about the Mono-list mailing list