Detail: [#834] bytecode test targets with C stubs cannot find needed .so

Bugs: Browse | Download .csv | Monitor

[#834] bytecode test targets with C stubs cannot find needed .so

Date:
2010-12-21 20:28 Priority:
3

State:
Open

Submitted by:
ygrek (ygrek) Assigned to:
Sylvain Le Gall (gildor-admin)

Due in version:
None Product:
OASIS

Operating System:
None Component:
OASIS

Version:
v0.2.0 Severity:
normal

Resolution:
None

URL:
http://build.ygrek.org.ua/hudson/job/extunix/label=qemu-armel-debian,ocaml=default/82/console

Summary:
bytecode test targets with C stubs cannot find needed .so

Detailed description
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.

Followup

Message
Date: 2010-12-23 09:20 Sender: Sylvain Le Gall > oasis can figure what stublibs Indeed, we can do that. > Unix.setenv We cannot access Unix module. We will need dynamic loading to access it or to compile setup.ml with it... (fallback into the same ocamlbuild scheme).
Date: 2010-12-23 09:08 Sender: ygrek > - 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
Date: 2010-12-22 13:05 Sender: Sylvain Le Gall OK. Lets go with 2) This means that running a test when there are C stubs will look like: env CAML_LD_LIBRARY_PATH=_build/src/ _build/src/myprog instead 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?
Date: 2010-12-22 12:30 Sender: ygrek I think I don't like it - extra scripts clutter working directory. setup.ml is already an uber-script that launches everything - let it set the environment too.
Date: 2010-12-22 11:38 Sender: Sylvain Le Gall 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. What do you think about that ?
Date: 2010-12-22 11:02 Sender: ygrek #562 suggests to go the custom route..

Attached Files:

Changes:

Field	Old Value	Date	By
assigned_to	none	2010-12-22 11:44	gildor-admin