[MLton-devel] mlton/doc CHANGES,1.62,1.63

[Stephen Weeks]

> I don't see how what you say could be the problem that I see.  Again, if I
> just run MLton then the resulting executable, as reported by ldd, needs
> the gmp shared library.  If, on the other hand, I do
> 	ar qc libgmp.a
> which makes a .a file with NO .o files in it, and then re-run MLton with
> 	-L`pwd`
> at the end, then the resulting executable does NOT need the gmp shared library.
> If there were any reference in any thing loaded to stuff in the gmp world then
> the linker would have failed to find it and so the link would have failed.
> Doesn't this prove that it your explanation fails to explain?

I think you are right Henry.  I just did some experiments using gcc to
compile a trivial C file, and the linker appears to add dependencies
on all shared libraries, whether or not they are needed, just as you
conjectured.  I see several ways to work around the problem.

1. Link against libgmp.a instead of libgmp.so.  I don't quite know how
to do this other than to specify the full path or have MLton would
have to search the lib path itself.  Anyone know?

2. MLton could do an nm on the object files before calling the linker.

3. MLton could know which primitives/ffi calls require linking against
the gmp.  MLton could check for these in the final RSSA or MACHINE
program.

If (1) is easy, I think that is the way to go.  Otherwise, I lean
towards (3), since it should run very quickly.

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel