[MLton] power pc "port"
Filip Pizlo
pizlo@purdue.edu
Fri, 3 Sep 2004 12:55:41 -0500 (EST)
> 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