[Mono-devel-list] A how to for Mono on OS X Panther Building (w/ JIT and GC to boot)

[Paolo Molaro]

Thanks for the writeup, Below my comments.

On 01/26/04 Dave Morford wrote:
> flags will result in a successful compile, link, install and that of 
> the 140 tests in the mono/tests directory, only 21 fail. Doing this on 

Are you running the tests with mint or with the jit? The results match
the current status of the jit on MacOSX 10.2, but on a 10.3 machine
I have access to there are a lot more errors (dunno yet why, debugging
is also a pain, since gdb keeps crashing). Did you test on a dual or
uniprocessor?

> 	1. Boehm GC 6.3a4 is required. I could never get the built-in 
> 	version, the stable version hand built or the port from DarwinPorts work.

Yes, previous versions of libgc were buggy, so, on MacOSX get the
version at: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source .
We'll include those sources in the mono package after the next release.

> 	3. I did not, and will not, try this on OS X Jaguar. The differences 
> are too great and I think using Panther as the working target for 
> success moving forward is the best option.

Mono builds and works ok for me on 10.2: the changes to keep it working
on both should be minimal (plus, I have 10.2 and no current plans of
upgrading;-).

> 2. Run the following tools in the order specified below in the root of 
> the mono snapshot:
> 
> glibtoolize --force --copy
> aclocal
> autoheader
> automake --add-missing --gnu
> autoconf

This is the same thing done by ./autogen.sh, so just running that should
work as well.

> 3. Run configure with these options:
> 
> ./configure --prefix=/usr/local --disable-static 
> LDFLAGS=-L/usr/local/lib CFLAGS=-I/usr/local/include 
> CPPFLAGS=-I/usr/local/include --with-gc=boehm 
> --program-transform-name=s/libtool/glibtool/

This last option should not be needed, at least I never used it, but
maybe it depends on the version of automake/libtool used.

> 4. Make the following change before running make:
> 	
> 	a. comment out the #ifdef __APPLE__ at the top of the file 
> mono/io-layer/sockets.h. This is not needed on 10.3, only 10.2.

This is now removed from the source, so this step should not be needed.

> 	b. in mono/mini, run: grep -n "version-script" Makefile. This should 
> return, at least on the 0.30 Previews, the following: 157:#monoldflags 
> = -Wl,-version-script=$(srcdir)/ldscript. If this line is not commented 
> out and/or has a ./ldscript instead of $(srcdir)/ldscript, you can 
> comment it out or remove the "-Wl,". I commented it out to no problems 
> as well as removed the "-Wl,", which fails when linking.

This step should not be needed as well, as you point out the flag is
already commented out on MacOSX.

> Tests on primes, fibonacci, reflection, language and runtime/vm objects 
> and ops (class, interface, cast, box, etc) all seem to pass in 
> mono/tests. PInvoke, threads, appdomains, vararg and setenv stand out 
> as tests that fail currently.

Exception-related tests should fail as well: I'm working on that code on
Linux/PPC currently, later I'll see how much of it can be reused on
MacOSX (which seems to require it's own thread to intercept mach
messages before they are converted to signals, sigh, I'd wish they'd fix
the signal implemenatation instead...).

> 1. Some of the assumptions in the configure scripts, in particular 
> threading, need to be examined. gcc does not need the -pthread flags to 

But using -pthread doesn't give any error, so this is a non-issue.

> 2. The ICU check looks for icu-config and fails but ICU *is* present on 
> OS X Panther in /usr/lib/libicucore.dylib but the icu-config tool is 
> not present. Perhaps a better check for this is possible? Does it need 
> to be linked in or is icu-config called or used anywhere?

It's called to collect the compile flags to use when linking it.
However, I had reports that the jit fails when icu is used, so I suggest
not trying to enable it in the meantime (you need to provide your own
icu-config script since it seems it's not installed by default).
Anyway, we're also dropping the libicu dependency, so it's not a big
issue.

> 3. Interop needs some work. I was able to get one or two PInvoke calls 
> through to some NS* objects in AppKit and Foundation in the Cocoa API, 
> but anything that did Windowing punted. I've just installed the latest 
> CHUD tools from Apple, so these will help in looking at the problems.

One issue to check for is if on 10.3, the default dl_open()
implementation works for shared libraries (as opposed to bundles).
I read somewhere that they may have the support, though it could be
half-assed (requires the complete path to the file etc.). If someone
could do a few tests on this and report it would be nice. If it works
that way we'll need to write our own code to support P/Invoke
(note we use the dl_* API through the GModule GLib interface).

As for the objective-C support, I'd like to handle it mostly in the same
way COM stuff is handled in the MS CLR on windows: a tool is used to
create assemblies whose types describe the objective-C classes, then the
runtime automatically marshals data between the CLR and the objective-C
world, etc.

Other tasks where people may help are:
*) support for mono --aot: this currently gives a few errors in the
assembly output, we need to adapt it to whatever the MacOSX assembler
accepts. A brave programmer could also contribute the code to build a
Mach-O binary directly...
*) of course, help debugging the errors we still get from the jit is
appreciated, especially if people have working debuggers on their
boxes:-)
*) later speed tuning needs to be done as well: currently the
performance of the jit is not bad, but we still have register allocation
and iniling disabled and there are quite a few arch-specific
optimizations that we could implement.

Thanks.
lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better