$ dune build
ocamlc test/test.bc (exit 2)
(cd _build/default && /home/san/.opam/4.08.1/bin/ocamlc.opt -w @1..3@5..28@30..39@43@46..47@49..57@61..62-40 -strict-sequence -strict-formats -short-paths -keep-locs -g -o test/test.bc /home/san/.opam/4.08.1/lib/ocaml/unix.cma /home/san/.opam/4.08.1/lib/ocaml/bigarray.cma /home/san/.opam/4.08.1/lib/integers/integers.cma /home/san/.opam/4.08.1/lib/ctypes/ctypes.cma /home/san/.opam/4.08.1/lib/ocaml/threads/threads.cma /home/san/.opam/4.08.1/lib/ctypes/ctypes-foreign-base.cma /home/san/.opam/4.08.1/lib/ctypes/ctypes-foreign-threaded.cma /home/san/.opam/4.08.1/lib/tsdl/tsdl.cma src/tsdl_image.cma test/.test.eobjs/byte/dune__exe__Test.cmo)
/usr/bin/ld : ne peut trouver -lctypes-foreign-threaded_stubs
/usr/bin/ld : ne peut trouver -lctypes-foreign-base_stubs
/usr/bin/ld : ne peut trouver -lctypes_stubs
/usr/bin/ld : ne peut trouver -lintegers_stubs
/usr/bin/ld : ne peut trouver -lintegers_stubs
collect2: error: ld returned 1 exit status
File "_none_", line 1:
Error: Error while building custom runtime system
Dune 2.0 changes the default target from @install to @all, so upgrading to (lang dune 2.0) will cause dune build to attempt to build more targets. In particular, executables with no public_name field (likely including your test binary) will be built by default whereas previously they were not.
If you run dune build @all on the project with (lang dune 1.11), do you get the same error?
indeed, yes!
thanks for the explanation.
But, I’m still missing something. Since dune test and dune exec test/text.exe both work, what is the ‘target’ that fails?
I’d guess the failing target is the bytecode test executable (dune exec ./test/test.bc); looks like your executable isn’t linking properly when compiled with ocamlc (and not ocamlopt).
You may want to add (modes exe) to the corresponding stanza to disable the bytecode target. This is the default post-2.0 anyway, so you can upgrade to get the same effect.
The Dune team are quite good at tying functional changes to language version, so the actual Dune version you’re using shouldn’t matter much w.r.t. correctness (except in that it places an upper bound on the lang version that you can use).
I’m not sure what’s happening in that case. My understanding is that from dune lang 2.0, (modes exe) is the default for executables (as this is what I interpret from the documentation).