Linker

The linker is a tool one can use to only ship the minimal possible set of functions that a set of programs might require to run as opposed to the full libraries.

Jb Evain started to work on the linker during the Summer Of Code 2006.

Why would one use the linker ?

There are a couple of scenarios for the linker:

• Reducing the size of a library.
• Creating a library based on a profile definition.

Because you don’t always use every feature of the libraries you are using for your program. By using the linker, you can reduce the size of what you have to distribute to your users.

Usage

mkbundle, the linker’s best friend

The linker operates only at the assemblies level. By using the mkbundle program, you can create a single executable which will contain the strict minimum it needs to run.

See the man page for mkbundle for details on its operation.

Download

For the moment, no versions has been released, but you can download the code from Git, in the module /mcs/tools/linker

Links

• Sample use of the linker
• Sample use of the Linker and mkbundle

Linker 2.0 Requirements

We would like to use the linker to generate multiple assemblies from the same code base. Instead of using an increasingly large number of ifdefs in the source code to add or remove features we would like to use the linker in this situation.

mscorlib handling: Currently the linker is not able to link mscorlib as it would accidentally remove fields that are shared between the C runtime and the managed code in mscorlib (and we must investigate if there are cases in System that also need to be handled specially). (Implemented in Git).

The linker should have a list of types whose fields must not be removed or reordered and that must be kept as they are.

blacklist support: This is an extension of mscorlib handling, but it should be possible for a user of the linker to specify a list of classes that should remain untouched. (Implemented in Git).

Profile-based Linking: The linker should support reading one of the .info files as generated by mono-api-info (in mcs/tools/CorCompare) and generate an assembly that contains the same API entry points. In this mode:

• The linker should turn any public types and members that are pulled by the mark process that are absent from the source profile into “internal” types or members to ensure that the public API does not expose more than it should.

• Handle base-classes that are not present. In a few cases (System.AppDomain) classes are made public because they are exposed by the inheritance chain should either be removed (_AppDomain interface) or we should decide on a case-by-case basis if it is worth exposing them.

For example, the following should be possible:

mkdir silverlight
monolinker -profile:mscorlib.silver.info /usr/lib/mono/full/mscorlib.dll -out:silverlight/mscorlib.dll