[MLton] power pc "port"

[Lukasz S Ziarek]

Regression info, the only ones listed are the ones that have failed:

fixed-integer - unhandled subscript exception non-zero exit status

and then we die on the modules test and the script halts, the linker could
not create a file called modules since a directory exists with that name.

Luke

On Fri, 3 Sep 2004, Filip Pizlo wrote:

> > 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
>
>
> _______________________________________________
> MLton mailing list
> MLton@mlton.org
> http://www.mlton.org/mailman/listinfo/mlton
>