[MLton] linking with GnuMP
Wed, 22 Dec 2004 17:38:08 -0800
A long time ago, we put in some effort so that MLton-generated
executables would only include the GnuMP library code (or add a
shared-library dependency) if the user program actually required
IntInf. Recent releases of MLton no longer achieve this goal, for
In the past we did the following:
1. The startup code in the include/ files only called the IntInf
initialization function if there were actually large IntInf constants
in the program.
2. The runtime separated IntInf into a separate file, and was careful
to only reference gmp stuff from that file.
3. The basis library dead-code elimination made sure that IntInf
functionality was only referred to only if it was actually used.
4. When calling the linker on Linux, main.fun tried to use libgmp.a
instead of libgmp.so because the linker added a dependency on a shared
library even if it isn't used.
As far as I can tell, (3) and (4) are still true, but (1) and (2)
aren't. The last release I can see that actually had the test for (1)
was 20011006! I don't even see the test in 20020923. Sometime around
then, the IntInf initialization code must have been moved into gc.c,
where it now stands (the initIntInfs function). The reference in gc.c
to mpn_set_str will at least cause that part of the GnuMP to be
On my Darwin machine, if I compile the empty mlb (i.e. no basis even),
the resulting executable has a single refernce to a gmp function
This makes sense. On my Linux machine, however, I get lots of
references to gmp functions.
0805c11c D __gmp_allocate_func
08052280 T __gmpn_add_n
080524b0 T __gmpn_mul
08056b70 T __gmpn_sub_n
This happens because of the special code to link with libgmp.a. If I
force the link to happen with -lgmp, then I get just gmpn_set_str. I
don't understand why the satic link causes everything to be brought
in, but whatever.
It seems to me that our current state is silly. As it stands, on
Linux, executables always include the full libgmp, and on other
platforms they always depend on the gmp shared library. I propose to
drop the special-case code in main.fun and accept the behavior of the
Linux linker. That way, Linux executables will be smaller. If users
want to link statically, they can use -link-opt -static. Also, since
we've lived with this state for a while, I don't see any need to go
the extra mile and figure out how to extract the reference to
mpn_set_str from gc.c.
I've argued before that we should link statically when compiling
MLton, to make it easier for people to install.
If we make the change I propose, we should also do this, since
otherwise we will be taking a step backward, as old MLton executables
on Linux don't depend on gmp while newer ones would.