This is a well known issue, the solution is to either :
1) install library prior to running tests
2) set the CAML_LD_LIBRARY_PATH when running tests
3) use -dllpath at compilation time
4) compile bytecode binaries with -custom

Ruling out options requiring user intervention (1) or compilation changes (3) and (4) we are left with option (2), i.e. `ocaml setup.ml -test` should setup CAML_LD_LIBRARY_PATH. The users who want to launch bytecode binaries "manually" can still install library or switch to custom compilation.

> - if there are more than one stub libraries, what do we do? Do we just allow access to both in the LD_LIBRARY_PATH? What if they have the same name?

oasis can figure what stublibs are used in the binary and put all the needed paths in LD_LIBRARY_PATH. If the stublibs have the same name then the program will not run anyway - ideally oasis should warn about this at some earlier stage.

> - Do you know the equivalent of UNIX's env for Windows?I thought of doing this with Unix.setenv both on unix and windows

This means that running a test when there are C stubs will look like:env CAML_LD_LIBRARY_PATH=_build/src/ _build/src/myproginstead of just calling_build/src/myprog

with _oasis:Test test Run: $myprog

Two questions:- if there are more than one stub libraries, what do we do? Do we just allow access to both in the LD_LIBRARY_PATH? What if they have the same name?- Do you know the equivalent of UNIX's env for Windows?

There is another way, but it is quite complex:- generate the binary myprog- generate a script myprog.sh that contains CAML_LD_LIBRARY_PATH and call myprog, in the same dir- set $myprog to myprog.sh rather than to myprog

This way, you will install myprog (and rely on target system to add the good LD_LIBRARY_PATH to access the .so library) and use myprog.sh during your test.