Libguestfs - Sep 2021 - [libguestfs PATCH 0/2] generalize ocaml-hivex[-devel] lookup

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

This series introduces the "lib/local/hivex.pc" pkg-config file to
hivex, permitting, through the "run" script, other programs and
libraries to be built against the just-built (not installed) hivex tree.
A few small details in the hivex build machinery that I understood to be
warts are cleaned up, and parts of the libguestfs tree *layout* are
adopted.

Thanks,
Laszlo

Laszlo Ersek (8):
  build: do not look for headers in "$(top_builddir)/lib"
  build: expose public library header "hivex.h" without
"lib" contents
  build: remove "hivex.pc" from EXTRA_DIST
  build: move "hivex.pc.in" to the "lib" subdirectory
  run: use 'prepend' function to build paths
  build: allow C programs using hivex to be compiled against build dir
  build: link hivex statically into C programs compiled against build
    dir
  build: allow OCaml programs using hivex to be compiled against build
    dir

 configure.ac                   |  4 ++-
 Makefile.am                    |  8 ++---
 images/Makefile.am             |  2 +-
 include/Makefile.am            | 20 +++++++++++++
 lib/Makefile.am                | 16 +++++++---
 ocaml/Makefile.am              | 21 ++++++++++++--
 perl/Makefile.PL.in            |  2 +-
 python/Makefile.am             |  2 +-
 ruby/Rakefile.in               |  2 +-
 sh/Makefile.am                 |  3 +-
 xml/Makefile.am                |  1 +
 .gitignore                     |  6 ++--
 generator/generator.ml         |  2 +-
 hivex.pc.in => lib/hivex.pc.in |  0
 lib/local/hivex.pc.in          | 35 ++++++++++++++++++++++
 run.in                         | 53 +++++++++++++++++-----------------
 16 files changed, 129 insertions(+), 48 deletions(-)
 create mode 100644 include/Makefile.am
 rename hivex.pc.in => lib/hivex.pc.in (100%)
 create mode 100644 lib/local/hivex.pc.in

-- 
2.19.1.3.g30247aa5d201

"daemon/Makefile.am" needs some tweaks for finding such OCaml bindings
for hivex that are not installed system-wide.

Thanks,
Laszlo

Laszlo Ersek (2):
  daemon: generalize ocaml-hivex[-devel] lookup
  daemon_utils_tests: generalize ocaml-hivex[-devel] lookup

 daemon/Makefile.am | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.19.1.3.g30247aa5d201