[Libguestfs] fixes for building libguestfs against a fresh hivex

Hi, the hivex tree provides a "run" script in its root directory, but it does not suffice for building / checking libguestfs, like this: libguestfs$ autoreconf -i libguestfs$ ../hivex/run ./configure CFLAGS=-fPIC libguestfs$ ../hivex/run make -j4 libguestfs$ ../hivex/run make -j4 check I'll post two small patch sets in-reply-to this cover letter, one for hivex and another for libguestfs, to enable the above usage. I regression-tested the patch sets in the following scenarios: - build & check libguestfs against the system-wide installed hivex packages - build & check guestfs-tools, and virt-v2v, against a libguestfs that was locally built against either a local hivex or a system-wide hivex. - did a bunch of "make dist"-based tests as well, such as out-of-source-tree builds and "make check"s of tar.gz-provided source trees. There were two major head-aches: - "daemon_utils_tests" is linked with a manually written LINK target that assumes hivex is in a system-wide location. It was difficult to recognize that the way to pass $(HIVEX_LIBS) to it was to extend the -cclib switch. (The OCaml documentation I managed to find wasn't stellar.) - A problem more at the design level: guestfsd links against hivex, but runs in the appliance. The daemon Makefile deals with this by translating the shared object dependencies of the executable to package (RPM) names, and then installing those RPMs in the appliance. This does not (and cannot) work when an RPM simply does not *exist* that could provide the locally-built hivex inside the appliance. The approach I chose was to link hivex statically into guestfsd, not dynamically. With that, a new set of challenges applied, as it is apparently autotools's mission to prevent statically linking *just one library* into an otherwise dynamic executable. I've read what there's to read about this on stackoverflow and elsewhere; automake *rejects* -Wl,-Bstatic / -Wl,-Bdynamic tricks in guestfsd_LDADD. Automake suggests guestfsd_LDFLAGS, but that is useless, as these flags are position-dependent, and they should only bracket $(HIVEX_LIBS) in guestfsd_LDADD. In the end, it wouldn't be right to modify guestfsd_LDADD anyway, as we don't *unconditionally* want hivex to be linked statically into guestfsd. So the next (and successful) idea was to modify the (new) "lib/local/hivex.pc" pkg-config descriptor in hivex with one more step: replace "-lhivex" with "-l:libhivex.a" on the "Libs:" line. This gets picked up in libguestfs's HIVEX_LIBS, and causes the linker to look specifically for "libhivex.a", not "libhivex.so". (Refer to the "-l" flags documentation in ld(1) -- I found the trick somewhere on stackoverflow.) A side effect is that *all* binaries built with "../hivex/run" will then get a static copy of the hivex library -- but that's a small price to pay. After all, such builds -- against a local (and not installed) hivex tree -- are always development builds. I've verified that the guestfsd executable still depends on the hivex *shared* object (and so the system-wide RPM) when "../hivex/run" is not in use. Thanks, Laszlo