On 08/04/2015 07:58 PM, Dave Chinner wrote:
That makes distclean do the same thing that realclean does and, as
that commit I pointed out previously, has been intentionally
separated in the build system. You could make the debian/rules file
simply call 'make realclean' rather than 'make distclean' to acheive
this without changing the main makefile. Either way, however, I
don't think that's the problem.
Yes, except I tried changing debian/rules to use realclean before coming up
with that idea and it broke the build.
make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4'
./configure $LOCAL_CONFIGURE_OPTIONS
configure: error: cannot find install-sh, install.sh, or shtool in . "."/.
Makefile:89: recipe for target 'include/builddefs' failed
make[1]: *** [include/builddefs] Error 1
make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4'
debian/rules:36: recipe for target '.census' failed
make: *** [.census] Error 2
Darrick Wong noted on #xfs that his builds of xfsprogs on ppc64el
from a tarball don't fail at all. His libtool chain is:
When I build xfsprog on ppc64el from a tarball, it does not fail at all either.
But in my case, specifically, it is because the tarball does not come with
a configure file (which would solve the problem I pointed out), so Makefile
generates it and runs libtoolize -c -i which updates the configuration files
needed.
host-triplet: powerpc64le-unknown-linux-gnu
libtoolize: (GNU libtool) 2.4.2 Debian-2.4.2-1.7ubuntu1
automake: automake (GNU automake) 1.14.1
autoconf: autoconf (GNU Autoconf) 2.69
Which is similar to mine, but libtoolize is slightly older (and I'm
on x86_64-pc-linux-gnu). It turns out that the reason the build
works on his machines is that someone had made a small manual change
to /usr/share/aclocal/libtool.m4:
--- a/libtool.m4 2014-02-11 04:58:49.000000000 -0800
+++ b/libtool.m4 2015-07-31 13:48:23.375432372 -0700
@@ -1312,7 +1312,7 @@
rm -rf conftest*
;;
-x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
# Find out which ABI we are using.
echo 'int i;' > conftest.$ac_ext
i.e. the problem looks to be that the libtool package shipped in
debian/unstable does not support ppc64el correctly....
Actually powerpc*-*linux* covers the triplet for ppc64el, as seen in:
>> host-triplet: powerpc64le-unknown-linux-gnu
So ppc*-*linux* does not make difference for ppc64el, if that is what you
refer to.
IMHO, if the debian src package xfsprogs came just like it comes in
git://oss.sgi.com/xfs/cmds/xfsprogs, ie clean, the build would not fail.
Thanks and regards.
--
Fernando Seiti Furusato
IBM Linux Technology Center
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
