[MLton-user] experimental release 20051109

[Matthew Fluet]

>> 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.