Re: [Libguestfs] Fwd: libguestfs incorrectly detects host CPU architecture

On Thu, Dec 12, 2019 at 11:01:02AM +0100, Vincent Danjean wrote: > [resend to the good (cloned) bug, sorry for the message in the original bug, > it was a mistake] > > Hi, > > On Thu, 5 Dec 2019 11:12:56 +0000 "Richard W.M. Jones" <rjones(a)redhat.com&gt; 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_@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) Pino, Hillu, what do you think?

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