compiling multifile program

compiling multifile program

[Lyn A Headley]

ok, so I tried to compile the simplest multifile program I could
think of, and I still get the "Undefined Global" error.  The files
are entry2.ml[i], qstring2.ml[i], and response2.ml

file entry2.ml:
let ent () = "hey";;

file entry2.mli:
val ent: unit -> string;;

file qstring2.ml:
let str () = "hi";;

file qstring2.mli:
val str: unit -> string;;

the "main file" response2.ml:
let s1 = Qstring2.str() and
    e1 = Entry2.ent() in
3;;

The error is:

Error while linking response2.cmo: Reference to undefined global `Qstring2'
make: *** [all] Error 2

If anyone could help, I would much appreciate it.
ocaml 1.04 SGI Irix 5.2

Lyn Headley

In case it should matter, Here's the Makefile:

OCC=ocamlc
OCDEP=ocamldep
INCLUDES= #all relevant -I options here
OCFLAGS=$(INCLUDES) -custom str.cma response2.ml unix.cma -cclib -lunix -cclib -lstr
# quiz should be compiled to bytecode, and is composed of three
# units: mod1, mod2 and mod3.

# Common rules
.SUFFIXES: .ml .mli .cmo .cmi

.mli.cmi:
        $(OCC) -c $<

.ml.cmo:
        $(OCC) -c $<

QUIZ_OBJS= entry2.cmo qstring2.cmo

all: $(QUIZ_OBJS)
        $(OCC) $(OCFLAGS) $(QUIZ_OBJS)

clean:
        rm -f *.cm[iox]

depend:
        $(OCDEP) $(INCLUDES) *.mli *.ml > .depend


include .depend

Re: compiling multifile program

[Pierre Weis]

[Résumé en Français]
[Le problème vient de l'ordre dans lequel sont donnés vos fichiers lors
de l'édition des liens: cet ordre est important en Caml, car les
définitions donnent lieu à des calculs arbitraires et doivent être
effectuées dans l'ordre de présentation donné par le programmeur.]

> ok, so I tried to compile the simplest multifile program I could
> think of, and I still get the "Undefined Global" error.  The files
> are entry2.ml[i], qstring2.ml[i], and response2.ml
[...]
> The error is:
> 
> Error while linking response2.cmo: Reference to undefined global `Qstring2'
> make: *** [all] Error 2
[...]
> Lyn Headley
> 
> In case it should matter, Here's the Makefile:
> 
> OCC=ocamlc
> OCDEP=ocamldep
> INCLUDES= #all relevant -I options here
> OCFLAGS=$(INCLUDES) -custom str.cma response2.ml unix.cma -cclib -lunix -cclib -lstr
> # quiz should be compiled to bytecode, and is composed of three
> # units: mod1, mod2 and mod3.
> 
> # Common rules
> .SUFFIXES: .ml .mli .cmo .cmi
> 
> .mli.cmi:
>         $(OCC) -c $<
> 
> .ml.cmo:
>         $(OCC) -c $<
> 
> QUIZ_OBJS= entry2.cmo qstring2.cmo
> 
> all: $(QUIZ_OBJS)
>         $(OCC) $(OCFLAGS) $(QUIZ_OBJS)
[...]

Your make file generates the following linking command:

ocamlc  -custom str.cma response2.ml unix.cma -cclib -lunix -cclib -lstr entry2.cmo qstring2.cmo

It is then clear that when linking response2.cmo (which is compiled on
the fly by your command) neihter entry2.cmo nor qstring2.cmo are
linked.

If you're puzzled by this explanation, remember that the order of
linking is relevant in Caml (and should be, since definitions may lead
to arbitrary computation that must be executed in order of
presentation). You should then start linking by entry2 or qstring2
that are self contained; afterwards you can link response2 that
depends on these two files.

I suggest to modify your make file. A quick and dirty hack is to
change the order of macros in the link command, from

>         $(OCC) $(OCFLAGS) $(QUIZ_OBJS)

to
         $(OCC) $(QUIZ_OBJS) $(OCFLAGS)

A better way is to add response2.cmo in the list of compiled files
used to built your program, being careful on the linking order:

QUIZ_OBJS= entry2.cmo qstring2.cmo response2.cmo

define OCFLAGS accordingly :

OCFLAGS=$(INCLUDES) -custom str.cma unix.cma -cclib -lunix -cclib -lstr

(by the way LINKFLAGS is more could be more appropriate)

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/