[Pkg-libvirt-maintainers] Bug#775761: libguestfs incorrectly detects host CPU architecture

[Vincent Danjean]

  Hi,

On Thu, 5 Dec 2019 11:12:56 +0000 "Richard W.M. Jones" <rjones at redhat.com> wrote:
> I believe this is a new bug and nothing much to do with:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761

  So I just cloned the bug into #946594 in order to manage the bug reported
by Pierre Neyron.

> However about this new bug, what is supposed to happen is that
> common/mlstdutils/guestfs_config.ml is generated by ./configure with
> the correct @host_cpu@ substituted.  If that's not happening then it's
> a build issue on Debian of some kind.

  I closely look at the build system with him. It occurs that :
- the Debian package use an 'out-of-source' build (ie the build is
  *not* done into the source directories)
- Debian applies some patches to archive this
- but the current rules about guestfs_config.ml especially target
  the source directory (whereas ./configure generates it in the
  build directory, as for all other configure generated files)

Easy test :
- remove common/mlstdutils/guestfs_config.ml in the source directory
- build the Debian package (dpkg-buildpackage -us -uc)
  => the build fails with:
ocamlfind ocamlopt -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 -ccopt '-g -O2 -fdebug-prefix-map=/home/polaris/danjean/libguestfs/libguestfs=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-overflow -Wno-strict-overflow' -package str,unix -I . -c ../../../../common/mlstdutils/std_utils.ml -o std_utils.cmx
File "_none_", line 1:
Warning 58: no cmx file was found in path for module Guestfs_config, and its interface was not compiled with -opaque

=> the guestfs_config.ml generated in the build directory is not
taken into account.
=> the Debian package is currently using the provided (x86-64)
guestfs_config.ml in the source directory and ignore the generated
one (in the build directory) on all architectures
=> the Debian package is correctly built only on x86-64...

  The root of the problem is in subdir-rules.mk at the root of the
package. I found a fix the seems to work:
=============
--- subdir-rules.mk	2019-12-11 15:45:01.274572831 +0100
+++ subdir-rules.mk.fixed	2019-12-11 15:44:23.738419530 +0100
@@ -79,12 +79,12 @@
 guestfs_am_v_jar_ = $(guestfs_am_v_jar_ at AM_DEFAULT_V@)
 guestfs_am_v_jar_0 = @echo "  JAR     " $@;

-%.cmi: $(srcdir)/%.mli
+%.cmi: %.mli
 	$(guestfs_am_v_ocamlcmi)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) $(OCAMLPACKAGES) -c $< -o $@
-%.cmo: $(srcdir)/%.ml
+%.cmo: %.ml
 	$(guestfs_am_v_ocamlc)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) $(OCAMLPACKAGES) -c $< -o $@
 if HAVE_OCAMLOPT
-%.cmx: $(srcdir)/%.ml
+%.cmx: %.ml
 	$(guestfs_am_v_ocamlopt)$(OCAMLFIND) ocamlopt $(OCAMLFLAGS) $(OCAMLPACKAGES) -c $< -o $@
 endif
=============

  The idea is to let "make" to check itself in the build directory and then
in the source directory by not forcing a path and using the VPATH feature
(as for all internal automake rules)

  Looking at the ChangeLog, I saw that the build rules about cmi/cmo/cmx/...
seems tricky, so I would prefer that someone that know ocaml builds checks
my patch.
  In any case, the Debian build is broken.
  As upstream does not seem to support out-of-source build, this problem should
not appear for it. So the fix can go into a debian patch (even if I think that
my patch is a no-op for a 'in-source' build)

  Regards,
    Vincent


> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> 
> 
> 

-- 
Vincent Danjean       GPG key ID 0xD17897FA         vdanjean at debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main