Bug#793495: xfsprogs fails to build on debian ppc64el

[Dave Chinner]

On Tue, Aug 04, 2015 at 12:24:06PM -0300, Fernando Seiti Furusato wrote:
> Hi Dave.
> 
> I have just noticed that for config.guess and config.sub to be updated, no
> autoreconf or dh_autotools-dev is needed, because of how Makefile was made.
> 
> In Makefile, @row 80:
> 
>  LIBTOOLIZE_INSTALL = `libtoolize -n -i >/dev/null 2>/dev/null && echo -i`
> 
>  configure:
>          libtoolize -c $(LIBTOOLIZE_INSTALL) -f
>          cp include/install-sh .
>          aclocal -I m4
>          autoconf
> 
> This runs libtoolize -c -i which updates those files.
> 
> The file debian/rules runs `make default`, which at some point calls the target
> above (`make configure`). But the file configure already exists, so it does not
> run.

Right. Intentionally so.

....

> diff -Nru xfsprogs-3.2.4/Makefile xfsprogs-3.2.4ppc64el1/Makefile
> --- xfsprogs-3.2.4/Makefile	2013-10-10 17:07:16.000000000 -0400
> +++ xfsprogs-3.2.4ppc64el1/Makefile	2015-08-04 11:06:40.000000000 -0400
> @@ -116,7 +116,7 @@
>  	$(Q)$(MAKE) $(MAKEOPTS) -C $* install-qa
>  
>  distclean: clean
> -	$(Q)rm -f $(LDIRT)
> +	$(Q)rm -f $(LDIRT) $(CONFIGURE)
>  
>  realclean: distclean
>  	$(Q)rm -f $(CONFIGURE) .gitcensus

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.

Darrick Wong noted on #xfs that his builds of xfsprogs on ppc64el
from a tarball don't fail at all. His libtool chain is:

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

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com