[MLton] power pc "port"

[Filip Pizlo]

> Here's what I suggest doing.  I'll assume that mlton.cvs.HEAD is where
> you have the CVS sources.
> 
> 1) copy the binary to
>      mlton.cvs.HEAD/mlton/mlton-compile
>    I'd keep a copy of the binary around somewhere else in case I get
>    something wrong here and make ends up deleting the binary.
> 2) fool the Makefile with
>      touch mlton.cvs.HEAD/mlton/mlton-compile
> 3) from mlton.cvs.HEAD run
>      make dirs runtime compiler
>    Assuming that you already have the runtime built, this should be fairly
>    quick -- it'll just copy a few things into mlton.cvs.HEAD/build/lib.
> 4) If that succeeds, we should be in good shape.  Try
>      make world-no-check
>    This will build the saved world described above.
> 5) Next there are a few auxilary things we need:
>      make script mlbpathmap
>    These shouldn't fail in any way.  The script will install
>    build/bin/mlton, the script that calls build/lib/mlton-compile.
> 6) Next we need to take care of some machine specific things (mostly
>    header file constants used by the basis library), so there's a chance
>    things will break here.  But you want to do:
>      make targetmap constants

This part failed, because /bin/cp has different semantics on Mac OS X than
on the other systems you guys use.  Basically, when trying to compile
tmp.c, I got a couple of pages or errors because platform/darwin.h was not
found.  This was because the top-level Makefile was copying the platform
directory as follows:

	$(CP) runtime/platform/ runtime/*.h include/*.h $(LIB)/include/

The problem is that when Mac OS X's /bin/cp sees a trailing '/' in the
source list, it copies the contents of the directory instead of the
directory itself.  So to make it work, I changed the Makefile so that
'platform' does not have a trailing '/' and then reran make
runtime.  After that, it all worked.

> 7) Finally, try type-checking the basis library:
>      make world
> 
> If you get to here, then it looks like you've got a working compiler.
> Running mlton.cvs.HEAD/build/bin should print something like:
>   MLton MLTONVERSION (built Thu Sep 02 19:21:08 2004 on tiger.cs.cornell.edu)

Yep, we get:

MLton MLTONVERSION (built Fri Sep  3 12:50:52 2004 on iBobTurbo)

> Next you can try out the regressions:
> 
> A) From mlton.cvs.HEAD, run
>      ./bin/regression

We fail on the first one as follows:

[pizlo@iBobTurbo mlton] ./bin/regression 
MLton MLTONVERSION (built Fri Sep  3 12:50:52 2004 on iBobTurbo)
flags = -type-check true 
testing 1
ld: Undefined symbols:
___gmpn_set_str
call to system failed with exit status 1:
gcc -o 1 /tmp/fileZ6DwE0.o /tmp/fileCf5c3O.o
-L/Users/pizlo/Programs/mlton/build/bin/../lib/self -lmlton -lgdtoa -lm

I notice that -lgmp is not in the library list.  On my computer, I had to
install gmp myself and whenever I build anything that uses it, I have to
include -lgmp in the list of link commands.  How does this work on the
other platforms?

Anyway, I'll use -target-link-opt to throw -lgmp in there to see how the
regressions do.

> > 1) I had to insert -D hacks to rename gdtoa's strof and strod, since
> > libSystem also has these.  This got rid of the linker warnings.
> 
> Hopefully there is a better way of dealing with this.

Yeah, it's pretty dirty the way it is.  I would prefer to have #define's
do this in gdtoa itself, but I see that you guys distribute gdtoa as a
tarball...  So I'm assuming that editing it directly is a no-no.

The thing is that this hack is only necessary to quiet the linker warnings
- mlton should still work even if we don't do it.  But I tend to feel that
getting rid of linker warnings is a good idea, especially from a usability
perspective.

--
Filip Pizlo
http://bocks.psych.purdue.edu/
pizlo@purdue.edu