[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PATCH] Don't rely on OCaml native compiler for tests

* Török Edwin:

> Try:
> $(LIBTOOL) --mode=execute -dlopen ../lib/libhivex.la $(OCAMLFIND) ...
> 'make check' appears to do that already automatically, so
> t/hivex_005_load runs correctly too.

This works for me. Great, thank you!

"make check", at least when it is called from within the ocaml
subdirectory, just sets LD_LIBRARY_PATH. Which comes pretty close to
what libtool would do, I suppose.

This seems to be defined by setting TESTS_ENVIRONMENT. BTW, can someone
tell me what the meaning of $(VG) right there?

Since the test programs are already listed, I have replaced the
individual "t/hivex_*_*" lines with this:

| t/%: t/%.cmo mlhivex.cma
| 	$(LIBTOOL) --mode=execute -dlopen $(top_builddir)/lib/libhivex.la \
| 	$(OCAMLFIND) ocamlc -dllpath $(abs_builddir) -package unix -linkpkg \
| 	mlhivex.cma $< -o $@

And it still builds and the tests run fine, at least on my amd64
Debian/unstable workstation.

Running the failing command under ltrace reveals that ocamlc uses
dlopen() to open dllmlhivex.so which is referenced by mlhivex.cma. Then
it uses dlsym(), apparently in order to verify that some symbols can be
resolved. This fails if libhivex.so.0 cannot be found, because
dllmlhivex.so depends on it.

Ah well, it seems I just got some steps closer to understanding how
autofoo and the OCaml toolchain operate.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]