ocamlbuild links libraries in wrong order - ocaml

I'm somehow trying to use _CoqProject parser from coq's library in OCaml (I'd welcome better alternatives to grab the .v files of a coq project if that library is not meant for external use, is it?), but ocamlbuild seems to be linking libraries in the wrong order.
Consider this minimal example file
open CoqProject_file
let x = read_project_file
The coq.lib package (bundled with coq) somehow depends on threads, and following this answer suggests to use -tag thread for that, but I still get the following error that threads is not found when linking coq.lib:
$ ocamlbuild -pkg coq.lib -tag thread -cflag -rectypes a.native /tmp/p
+ /home/sam/.opam/4.06.0+coq-8.7/bin/ocamlopt.opt -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/config -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib -I /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/str.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/unix.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa -thread threads.cmxa a.cmx -o a.native
File "_none_", line 1:
Error: No implementations provided for the following modules:
Thread referenced from /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa(Exninfo)
Mutex referenced from /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa(Exninfo)
Command exited with code 2.
Yet that compiles if I take the ocamlopt invocation apart and put -thread threads.cmxa before clib.cmxa
$ cd _build/
$ /home/sam/.opam/4.06.0+coq-8.7/bin/ocamlopt.opt -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/config -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib -I /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/str.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/unix.cmxa -thread threads.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa a.cmx -o a.native
What is the right way to call ocamlbuild?

If you use ocamlfind packages, you should use the -use-ocamlfind flag.
There is no good solution as to why -tag thread is needed¹. There are two different implementations of the OCaml Threads interface (one with os threads and one with green threads), and coq.lib depends on the interface but won't decide for the user which one to use, so you have to specify it manually, for example by using -tag thread.
¹: one solution would be to remove this choice by deprecating vmthreads (the green threads), which is rarely used in practice.

Related

how to chose between two implementation code in OCaml

I have uploaded the very small exemple project on a github repository
I have a school project. The specifications say that we can enable or disable a component.
I came from the c world in which we can compile c to object and chose the object to link. I try this in OCaml.
I have two source file with the same function but their effect is different.
I have two folders called "on" with implementation and "off" folder with an empty body
For the test, I have a simple a.ml and a.mli file that only print hello world and b.mli b.ml that call the module a. (so I have on/a.ml and off/a.ml)
I compile the on version and the off with this command:
ocamlc -c -I on on/a.mli on/a.ml -o on/a.cmo
then I try to link the C-way
ocamlc on/a.cmo b.ml -o on_b.exe
but I get the error
File "b.ml", line 1, characters 9-15:
Error: Unbound module A
I have then read I should specify the folder to search in with -I.
ocamlc -I on -I off on/a.cmo b.ml -o on_b.exe
I was happy because of that work for the on version
but it will not work for the off version
ocamlc -I on -I off off/a.cmo b.ml -o off_b.exe
I get the error
Error: Files b.cmo and off/a.cmo
make inconsistent assumptions over interface A
I have inspected with ocamlobjinfo it seems to build B its searches for the first module called A
In this example, I have only A and B but in future, I will build with some version on and some off... but don't do it manually
A solution found but no really efficient is to clean all .cmo and .cmi files ...
thanks for your reading and your time
EDIT:
I have also test with -open but it seems to work only for standards modules.
As you can see, compiling your .mli files produces a .cmi file. This is the file that you indicate is there by using the -I dir option.
So, if I understand you correctly, you have a a.mli in both your on and your off directory.
Now, when you refer to the module A in your code, the compiler looks for it in the current directory, then in the linked directories in the order they are given. When you compile "on", the right .cmi is found (because -I on comes before -I off in your command line). In the case of "off", the "on" cmi is found, and the compiler sees that it doesn't correspond to the right cmo.
Your two compiling lines should be:
ocamlc -I on on/a.cmo b.ml -o on_b.exe
ocamlc -I off off/a.cmo b.ml -o off_b.exe

How to separate binary code from source in ocaml?

I have my source next to a build directory
ocamlc -c file1.ml
ocamlc -c file2.ml
…
ocamlc -o main.ml ….cmo
I have the source with the file generated by the compilation.
I would like an option of ocamlc that enable me to have this file in the build directory.
I know i can do ocamlc -o build/main.ml .....cmo but i would like to have to .cmo in the build directory too
Thank you for your help
The answer of your main question is very simple:
in order to put the main binary of your OCaml application in the build folder, you just need to run:
ocamlc -o build/main.exe main.ml ….cmo
Indeed as indicated in the documentation (man ocamlc):
-o exec-file
Specify the name of the output file produced by the linker. The
default output name is a.out, in keeping with the Unix tradition. […]
However, doing all the build steps by hand in the way you are suggesting in your question may not be very effective (in particular, all .cmo files will stay along with the sources in the same folder).
To avoid this and facilitate the build of your OCaml project, I suggest using a build management tool for OCaml, for example one of the four tools mentioned in the end of the tutorial Compiling OCaml Projects:
ocamlbuild
GNU make
OMake
Oasis
(ocamlbuild is probably the easiest tool to use among the four.)
But you may also consider using Dune (formerly known as JBuilder), which is the build system used by a majority of packages in opam.

MirageOS - Unable to build unikernel for XEN

I've written a simple MirageOS-based Unikernel to execute a basic HTTP GET call. While it is working without any problems when I run it as a Unix binary, the moment I configure it for XEN (mirage configure --xen) and launch the make command, I get the following error:
ocamlbuild -use-ocamlfind -pkgs lwt.syntax,cohttp.lwt,cohttp.lwt-core,mirage-console.xen,mirage-http,mirage-types.lwt -tags "syntax(camlp4o),annot,bin_annot,strict_sequence,principal" -tag-line "<static*.*>: -syntax(camlp4o)" -cflag -g -lflags -g,-linkpkg,-dontlink,unix main.native.o
+ ocamlfind ocamlopt -g -linkpkg -dontlink unix -output-obj -package mirage-types.lwt -package mirage-http -package mirage-console.xen -package cohttp.lwt-core -package cohttp.lwt -package lwt.syntax -syntax camlp4o unikernel.cmx main.cmx -o main.native.o
File "_none_", line 1:
Error: No implementations provided for the following modules:
Unix referenced from /home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_engine),
/home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_unix),
/home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_io),
/home/mirage/.opam/system/lib/lwt/lwt-unix.cmxa(Lwt_log),
/home/mirage/.opam/system/lib/ipaddr/ipaddr_unix.cmxa(Ipaddr_unix),
/home/mirage/.opam/system/lib/xenstore_transport/xenstore_transport_lwt_unix.cmxa(Xs_transport_lwt_unix_client),
/home/mirage/.opam/system/lib/conduit/conduit-lwt-unix.cmxa(Conduit_lwt_unix),
/home/mirage/.opam/system/lib/cohttp/cohttp_lwt_unix.cmxa(Cohttp_lwt_unix_debug),
/home/mirage/.opam/system/lib/cohttp/cohttp_lwt_unix.cmxa(Cohttp_lwt_unix)
Command exited with code 2.
Compilation unsuccessful after building 7 targets (0 cached) in 00:00:03.
make: *** [main.native.o] Error 10
I just started working with MirageOS and OCaml so it might be a stupid question but right now I really don't know what to do.
You should not use Cohttp_lwt_unix. As the name suggests, it runs on unix, not on xen. If you want an example of a webserver that is xen-proof, you can look at this skeleton or at the code used by mirage-seal.
As #Drup says, you need to avoid any "unix" packages if you want to be portable. Instead, use a Mirage adaptor for cohttp. This one should work:
https://github.com/mirage/mirage-http

OCaml: Reference to undefined global `A`

I have a three signatures A.mli,B.mli,and C.mli. Within them I have submodules Aa, Bb, and Cc respectively and also a signature for the implementations Ai, Bi, and Ci.
I have implemented them in a file called D.ml which looks like this
open A
open B
open C
module Ai : Aa = struct ... end
module Bi : Bb = struct ... end
module Ci : Cc = struct ... end
I compile them each in turn with the following commands:
ocamlfind ocamlc -linkpkg -thread -package core A.mli
ocamlfind ocamlc -linkpkg -thread -package core B.mli
ocamlfind ocamlc -linkpkg -thread -package core C.mli
ocamlfind ocamlc -linkpkg -thread -package core D.ml
which all succeed.
I then have a file E.ml where I try to use the modules Ai, Bi, Ci.
open A
open B
open C
module M = Ai(Ci)
(* do something else *)
However when I try to compile E.ml I get the
Error: Error while linking E.cmo:
Reference to undefined global `A`
I think I have to somehow include D.ml in the compilation step but I'm unsure how to.
Using ocamlc or ocamlopt compiler directly (even with the help of ocamlfind) is not an easy task, and should be left only for those, who write OCaml tools and very sure in what they're doing. So, in short, just use ocamlbuild, that is the default way of compiling things in OCaml world. Since, you're using Core library it would be also a good idea to use corebuild instead of ocamlbuild. corebuild is shipped with core, and is actually a small wrapper around ocamlbuild, that adds core dependencies, as well as some handy flags. So, with corebuild you can compile just with:
corebuild E.native
Without corebuild, you can compile with
ocamlbuild -pkg core E.native
ocamlbuild will do all the work for you, i.e., find all dependencies, sort them in correct order, invoke proper tools, etc... You just need this one, command.
If you're still interested in how to compile your example project properly, then you can ask ocamlbuild about this. Use -classic-display option, that will show you all intermediate commands,
ocamlbuild -use-ocamlfind -classic-display -pkg core E.byte
Will show you all steps. (You may need to ocamlbuild -clean, so that you can see all the steps from the start).

How to use -thread compiler flag with ocamlbuild?

I am using Jane Street's async_core by adding package(async_core) in _tags.
When I use ocamlbuild -use-ocamlfind -I src test/test_airport.native, it gives me the following error:
camlfind ocamlopt -linkpkg -package async_core -package unix -package
netclient -package mongo -package xml-light src/airport.cmx
test/test_airport.cmx -o test/test_airport.native ocamlfind: Error
from package `threads': Missing -thread or -vmthread switch
I googled it and here is what I got http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual039.html
It says:
Programs that use system threads must be linked as follows:
ocamlc -thread other options unix.cma threads.cma other files
So I changed my ocamlbuild command like this:
ocamlbuild -use-ocamlfind -cflag -thread -I src test/test_airport.native
But the error remains the same. also the actual command that ocamlbuild generated remains the same without -thread.
How can I deal with this?
What you want to know is whether there is an ocamlbuild tag (~ feature) to add the -thread argument to the relevant command-lines, instead of hacking it with -cflag in unsatisfying ways. As explained in this blog post, you should use the -documentation option of ocamlbuild:
% ocamlbuild -documentation | grep thread
flag {. byte, link, ocaml, program, thread .} "threads.cma -thread"
flag {. link, native, ocaml, program, thread .} "threads.cmxa -thread"
flag {. doc, ocaml, thread .} "-I +threads"
flag {. compile, ocaml, thread .} "-thread"
So the answer is: add -tag thread to your ocamlbuild invocation
line, or just thread in the relevant place in _tags.