Why does the order in the Makefile matter? --- Linking with C

[kahl@heraklit.informatik.UniBw-Muenchen.de]

Pierre Weis <Pierre.Weis@inria.fr> wrote:
 
> Hence, when the entire program is made of multiple implementation
> files, those files must be linked in any order that is compatible with
> the static binding rule: no definition can be linked if it refers to
> an identifier that is defined after the definition at hand.  In
> addition, expressions to be computed must evidently appear in any
> order compatible with the desired runtime behaviour.

However, yesterday I experimented with implementing a system call in C
(why does the standard library only provide sleep with a granularity of
 whole seconds?),
and I linked it together with the .cmx file containing the external definition
into utils.cmxa.

Then I proceeded to link my application, consisting of other *.ml modules
that use stuff from utils.cmxa, including that external function:

ocamlopt ... -o application utils.cmxa others1*.cmxa others2*.cmx

The result was a link error that the system call could not be found.
(The analogous bytecode variant compiles without complaints,
 but I only use the bytecode compiler as a kind of ``lint''.)
So I had to take utilsC.o out of utils.cmxa and revert to:

ocamlopt ... -o application utils.cmxa others1*.cmxa others2*.cmx utilsC.o

This is logical with my understanding of C linking,
but I would prefer not to have to use that knowledge... ;-)

Is this asymmetry known/documented/on purpose?


Best regards,

Wolfram Kahl