Laszlo Ersek
2021-Sep-08 12:44 UTC
[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
Laszlo Ersek
2021-Sep-08 13:27 UTC
[Libguestfs] [hivex PATCH 0/8] add a pkg-config descriptor for the local (not installed) build tree
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
Laszlo Ersek
2021-Sep-08 13:35 UTC
[Libguestfs] [libguestfs PATCH 0/2] generalize ocaml-hivex[-devel] lookup
"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