"make distcheck" failure
Hi Rich, I ran these commands as non-root: ./autogen.sh && make && make distcheck It got most of the way through, but failed in the VPATH part while rebuilding from a ./_build subdir, like this: make[4]: Entering directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' mkdir -p /usr/lib64/ocaml mkdir -p /usr/lib64/ocaml/stublibs ocamlfind install \ -ldconf ignore -destdir /usr/lib64/ocaml \ hivex \ META *.so *.a *.cma *.cmi ../../ocaml/*.mli *.cmx *.cmxa ocamlfind: Cannot mkdir /usr/lib64/ocaml/hivex: Permission denied make[4]: *** [install-data-hook] Error 2 make[4]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[3]: *** [install-data-am] Error 2 make[3]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build' make: *** [distcheck] Error 1 Obviously, it should not be trying to create directories under /usr.
On Tue, Aug 28, 2012 at 11:59:11AM +0200, Jim Meyering wrote:
Hi Rich,
I ran these commands as non-root:
./autogen.sh && make && make distcheck
It got most of the way through, but failed in the VPATH part while rebuilding from a ./_build subdir, like this:
make[4]: Entering directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' mkdir -p /usr/lib64/ocaml mkdir -p /usr/lib64/ocaml/stublibs ocamlfind install \ -ldconf ignore -destdir /usr/lib64/ocaml \ hivex \ META *.so *.a *.cma *.cmi ../../ocaml/*.mli *.cmx *.cmxa ocamlfind: Cannot mkdir /usr/lib64/ocaml/hivex: Permission denied make[4]: *** [install-data-hook] Error 2 make[4]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[3]: *** [install-data-am] Error 2 make[3]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build' make: *** [distcheck] Error 1
Obviously, it should not be trying to create directories under /usr.
The rule in the Makefile.am is: install-data-hook: mkdir -p $(DESTDIR)$(OCAMLLIB) mkdir -p $(DESTDIR)$(OCAMLLIB)/stublibs $(OCAMLFIND) install \ -ldconf ignore -destdir $(DESTDIR)$(OCAMLLIB) \ $(PACKAGE_NAME) \ $(install_files) So that must mean that DESTDIR is not being set. There are also environment variables that ocamlfind itself will use (see findlib.conf(5)). Although they don't appear to be relevant here it may be worth looking at that man page. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
Richard W.M. Jones wrote:
On Tue, Aug 28, 2012 at 11:59:11AM +0200, Jim Meyering wrote:
Hi Rich,
I ran these commands as non-root:
./autogen.sh && make && make distcheck
It got most of the way through, but failed in the VPATH part while rebuilding from a ./_build subdir, like this:
make[4]: Entering directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' mkdir -p /usr/lib64/ocaml mkdir -p /usr/lib64/ocaml/stublibs ocamlfind install \ -ldconf ignore -destdir /usr/lib64/ocaml \ hivex \ META *.so *.a *.cma *.cmi ../../ocaml/*.mli *.cmx *.cmxa ocamlfind: Cannot mkdir /usr/lib64/ocaml/hivex: Permission denied make[4]: *** [install-data-hook] Error 2 make[4]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[3]: *** [install-data-am] Error 2 make[3]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build/ocaml' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/h/j/w/co/hivex/hivex-1.3.6/_build' make: *** [distcheck] Error 1
Obviously, it should not be trying to create directories under /usr.
The rule in the Makefile.am is:
install-data-hook: mkdir -p $(DESTDIR)$(OCAMLLIB) mkdir -p $(DESTDIR)$(OCAMLLIB)/stublibs $(OCAMLFIND) install \ -ldconf ignore -destdir $(DESTDIR)$(OCAMLLIB) \ $(PACKAGE_NAME) \ $(install_files)
So that must mean that DESTDIR is not being set.
There are also environment variables that ocamlfind itself will use (see findlib.conf(5)). Although they don't appear to be relevant here it may be worth looking at that man page.
Hi Rich, In Makefile.am files, installation-related rules must honor the $(prefix) Makefile variable. For example, in many Makefiles you'll find files being installed to $(DESTDIR)$(bindir), with these definitions: bindir = ${exec_prefix}/bin exec_prefix = ${prefix} Currently, $(OCAMLLIB) (set from m4/ocaml.m4 by running $OCAMLC) is set to /usr/lib64/ocaml for me. If we could make it include $(exec_prefix), that would solve this problem.
On Tue, Aug 28, 2012 at 05:46:49PM +0200, Jim Meyering wrote:
In Makefile.am files, installation-related rules must honor the $(prefix) Makefile variable. For example, in many Makefiles you'll find files being installed to $(DESTDIR)$(bindir), with these definitions:
bindir = ${exec_prefix}/bin exec_prefix = ${prefix}
Currently, $(OCAMLLIB) (set from m4/ocaml.m4 by running $OCAMLC) is set to /usr/lib64/ocaml for me. If we could make it include $(exec_prefix), that would solve this problem.
I see. Not an easy one to solve however. The OCaml library path comes from running: $OCAMLC -where This is not an (especially) peculiar OCaml thing. For example we detect the Python library path using: $PYTHON -c "import distutils.sysconfig; \ print (distutils.sysconfig.get_python_inc ());" This allows multiple parallel Python installations to get along on Debian. The user just specifies the $PYTHON binary and everything works off that. So I'm fairly sure the same bug exists in some Python, Perl and Ruby code in libguestfs too. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
Richard W.M. Jones wrote:
On Tue, Aug 28, 2012 at 05:46:49PM +0200, Jim Meyering wrote:
In Makefile.am files, installation-related rules must honor the $(prefix) Makefile variable. For example, in many Makefiles you'll find files being installed to $(DESTDIR)$(bindir), with these definitions:
bindir = ${exec_prefix}/bin exec_prefix = ${prefix}
Currently, $(OCAMLLIB) (set from m4/ocaml.m4 by running $OCAMLC) is set to /usr/lib64/ocaml for me. If we could make it include $(exec_prefix), that would solve this problem.
I see. Not an easy one to solve however. The OCaml library path comes from running:
$OCAMLC -where
A slightly kludgey (pragmatic?) fix would be to transform the current $OCAMLLIB by these in ocaml.m4: s,/usr/lib64/,$(exec_prefix)/lib64, s,/usr/lib/,$(exec_prefix)/lib, However, that would work only if ocamlc is installed in the normal system-wide location. It would not work if you are using a version of ocamlc that you installed using --prefix=$HOME/ocaml. For cases like that (where the above substitutions make no change), the easiest/safest would be to abort the configure script. Perhaps easier still, but not safe, would be to allow the configure/build to proceed, but then "make distcheck" could end up modifying files under $HOME/ocaml for those whose ocamlc has a writable OCAMLLIB directory. Currently, if root runs "make distcheck", I suspect it would put things in $OCAMLLIB. That would be rather antisocial, but maybe you have something to abort a "make distcheck" when it's run by root? I haven't tried that.
This is not an (especially) peculiar OCaml thing. For example we detect the Python library path using:
$PYTHON -c "import distutils.sysconfig; \ print (distutils.sysconfig.get_python_inc ());"
This allows multiple parallel Python installations to get along on Debian. The user just specifies the $PYTHON binary and everything works off that. So I'm fairly sure the same bug exists in some Python, Perl and Ruby code in libguestfs too.
Rich.
On Tue, Aug 28, 2012 at 06:33:34PM +0200, Jim Meyering wrote:
Currently, if root runs "make distcheck", I suspect it would put things in $OCAMLLIB. That would be rather antisocial, but maybe you have something to abort a "make distcheck" when it's run by root? I haven't tried that.
The truth of the matter is that we don't use make distcheck. The [not open-sourced yet] whenjobs-based release scripts build a candidate tarball from git (ie. make dist). Said tarball is then sent to several build servers which './configure && make && make check' it. So no distcheck is required, and what we are doing now is arguably more thorough. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
Richard W.M. Jones wrote:
On Tue, Aug 28, 2012 at 06:33:34PM +0200, Jim Meyering wrote:
Currently, if root runs "make distcheck", I suspect it would put things in $OCAMLLIB. That would be rather antisocial, but maybe you have something to abort a "make distcheck" when it's run by root? I haven't tried that.
The truth of the matter is that we don't use make distcheck.
The [not open-sourced yet] whenjobs-based release scripts build a candidate tarball from git (ie. make dist). Said tarball is then sent to several build servers which './configure && make && make check' it. So no distcheck is required, and what we are doing now is arguably more thorough.
Glad to know that in some respects your procedure is more thorough. However, please consider making it run a non-srcdir build and install like "make distcheck" does, so that problems like this are caught before release. I would be rather upset if a standard test build+install with --prefix=/tmp/junk in the style of what "make distcheck" does were to deposit build artifacts in my personal (or system-wide, when run as root) installation directories.
On Aug 28, 2012, at 09:52 , Jim Meyering wrote:
Richard W.M. Jones wrote:
On Tue, Aug 28, 2012 at 06:33:34PM +0200, Jim Meyering wrote:
Currently, if root runs "make distcheck", I suspect it would put things in $OCAMLLIB. That would be rather antisocial, but maybe you have something to abort a "make distcheck" when it's run by root? I haven't tried that.
The truth of the matter is that we don't use make distcheck.
The [not open-sourced yet] whenjobs-based release scripts build a candidate tarball from git (ie. make dist). Said tarball is then sent to several build servers which './configure && make && make check' it. So no distcheck is required, and what we are doing now is arguably more thorough.
Glad to know that in some respects your procedure is more thorough.
However, please consider making it run a non-srcdir build and install like "make distcheck" does, so that problems like this are caught before release. I would be rather upset if a standard test build+install with --prefix=/tmp/junk in the style of what "make distcheck" does were to deposit build artifacts in my personal (or system-wide, when run as root) installation directories.
I've had some less than ideal situations building Hivex that I think running `make distcheck` (with whenjobs) would resolve - or at least make apparent. One is with the Python bindings not respecting --prefix. ``make distcheck`` fails when trying to install the bindings into the system Python directory. (Separately, I can't easily apply the ostrich algorithm to this issue: --disable-python doesn't work, either. <https://bugzilla.redhat.com/show_bug.cgi?id=730776>) I'm curious, do your buildservers use gitbuilder, or something else to determine the commits to build? I like the look of whenjobs; what's the appropriate mailing list for that utility? --Alex
On Tue, Aug 28, 2012 at 12:52:36PM -0700, Alex Nelson wrote:
I'm curious, do your buildservers use gitbuilder, or something else to determine the commits to build? I like the look of whenjobs; what's the appropriate mailing list for that utility?
There's no mailing list at the moment. Attached is the current whenjobs script for libguestfs git/rawhide. There's actually a lot more to the build system since it builds other branches of libguestfs and other programs entirely, but this is a good start. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
participants (3)
-
Alex Nelson -
Jim Meyering -
Richard W.M. Jones