OCaml Forge

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)
Product:
OASIS
Due in version:
None
Resolution:
None
Severity:
normal
Version:
0.2.0
Component:
OASIS
Operating System:
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_tonone2010-12-22 11:44gildor-admin