[Mono-list] (MacOSX) Requesting porting guide clarifications

[Ryan Wilhm]

Thanks! Follow-ups below. Also, things are progressing... I'm able to build
the mono-0.9 drop now, though I'm having some quirks with the glib gmodule
loading, so mint isn't really able to run yet. (I guess Apple decided to
make the distinction between shared libraries and loadable modules, whereas
Linux ELF systems treat shared code as something that can be used as a
library and for dynamic loading *and* unloading... After dinking the glib
build to set the suffix to '.bundle' for Darwin systems and compiling
against dlcompat, glib seemed happy, but I'm not really sure if that's all
that needs to be done...)

On 2/28/02 12:27 PM, "Miguel de Icaza" <miguel@ximian.com> wrote:

>> 1. Re: The current guidelines
>> Am I correct in assuming that I don't need to mess with the PPC arch
>> implementation? I know this is currently underway for PPC based Linux
>> distros, but I'm assuming the CLI bytecode to native code should map 1:1
>> irregardless. I'm also proceeding under the assumption that porting the JIT
>> is not really a concern at the moment, and that I should focus on making
>> sure the interpreter works first and foremost.
> 
> Yes, this is correct.  Most of the low-level PPC work has been now
> completed by Radek Doulik now.  The areas that might need work are at
> the Unix porting level, and they could encompass some of these:
> 
> * Threads, but we believe Jeff's work on Solaris should have
>  taken care of most of the portability issues.
> 

Yes, this was a tremendous help. (He was also nice enough to help me get
started. :)

The last issue with this was that Darwin/OS X doesn't support pthread_rwlock
operations. (Required by events.c in io-layer.) I remembered that the
O'Reily Pthreads book had a read/write locking implementation in it as an
example, so I basically rehashed that as a placeholder for now. Jeff
mentioned the portable thread library from GNU as something to look into...

> * Signal handling (we need information about the signal, and how
>  to modify registers after we catch a signal for example, and
>  to unwind the stack).  This might be different in Linux than
>  the Mac OS X. 
> 
>> 2. Specifying platform specific behavior in the code
>> There have been a few problems that I fixed by using macros. Is that cool?
>> Apple has defined "__APPLE__" in it's headers, so I've been using that to
>> single out OS X platform fixes. Is this cool? Would it be more appropriate
>> to define a macro specific to the Mono build to tag OS X behavior? Or, is
>> this totally wrong?
> 
> This works, but we would surely like to look at what you are ifdefing
> out.  Sometimes the best way to port is to "probe" for the capability,
> rather than the vendor.  If you probe for the capability, you can also
> simplify the life of other people porting to other systems, but most
> importantly, if your vendor revisits its interface and decides to
> add/remove features in the future, recompiling Mono will take advantage
> of these features.
> 

Thanks, I didn't think to look at either of these things. For the second,
I'll probably keep the macros for the moment until things work, but will
definitely revisit this before submitting a patch.

Thanks, again!
Ryan




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com