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

[Richard W.M. Jones]

On Tue, May 10, 2011 at 11:54:27PM +0200, Hilko Bengen wrote:
> * 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?

It's so you can do:

  make VG=valgrind check

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

Do you have a suggested patch?  This all works fine for me (even on
Debian) so I don't understand what the exact problem was.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top