[MLton-user] experimental release 20051109
Matthew Fluet
fluet@cs.cornell.edu
Mon, 14 Nov 2005 22:24:41 -0500 (EST)
>> Of course, everything works with what's currently in the SVN.
>
> Sadly, that I can't say.
> I ran into this bug too, but didn't report it.
> Anyone who has Tiger has this problem.
>
> It doesn't work for me; I've been trying.
> The .o compiles, but the link fails:
>
> gcc -std=gnu99 -c -I/usr/local/lib/mlton/include -O1 \
> -fno-strict-aliasing -fomit-frame-pointer -w -I/sw/include \
> -fno-tree-ch -o /tmp/file9ffQ3w.o /tmp/filehrnJPQ.0.c
> Compile C and Assemble finished in 10.68 + 0.01 (0% GC)
> Link starting
> gcc -std=gnu99 -o ufo /tmp/fileCIjGJj.o /tmp/file5wbjrn.o \
> /tmp/file9ffQ3w.o -L/usr/local/lib/mlton/self -lmlton -L/sw/lib \
> -lgmp -lgdtoa -lm
> /usr/bin/ld: Undefined symbols:
> _MLtonProfile1648
> _MLtonProfile903
> /usr/bin/ld: warning weak symbol references not set in output with
> MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1
> /usr/bin/ld: warning weak referenced symbols:
> _MLtonProfile1648
> _MLtonProfile903
> collect2: ld returned 1 exit status
Could you try compiling with -cc-opt -O0 ? From the errors above, it
appears that your environment isn't NULL-ing out dropped weak references.
Just as there is a problem if gcc chooses to duplicate some of our
profiling labels, there is a problem if gcc chooses to drop some profiling
labels. We've tried working around that scenario by having the uses of
the profiling labels (to populate a static table) used as weak references,
so that if the corresponding basic blocks are dropped by gcc, then there
won't be any unbound symbols.