From: Fernando Seiti Furusato <ferseiti@linux.vnet.ibm.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com, 793495@bugs.debian.org,
Breno Leitao <brenohl@br.ibm.com>,
Daniel Bast <daniel.bast@gmx.net>
Subject: Re: Bug#793495: xfsprogs fails to build on debian ppc64el
Date: Wed, 05 Aug 2015 10:00:02 -0300 [thread overview]
Message-ID: <55C208D2.4060907@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150804225819.GV16638@dastard>
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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-08-05 13:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 15:21 xfsprogs fails to build on debian ppc64el Daniel Bast
2015-07-31 21:57 ` Fernando Seiti Furusato
2015-08-01 22:52 ` Dave Chinner
2015-08-02 13:06 ` Bug#793495: " Daniel Bast
2015-08-02 22:13 ` Dave Chinner
2015-08-04 15:24 ` Fernando Seiti Furusato
2015-08-04 22:58 ` Dave Chinner
2015-08-05 13:00 ` Fernando Seiti Furusato [this message]
2015-08-05 13:47 ` Dave Chinner
2015-08-05 15:52 ` Fernando Seiti Furusato
2015-08-06 0:21 ` Dave Chinner
2015-08-06 7:10 ` Nathan Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55C208D2.4060907@linux.vnet.ibm.com \
--to=ferseiti@linux.vnet.ibm.com \
--cc=793495@bugs.debian.org \
--cc=brenohl@br.ibm.com \
--cc=daniel.bast@gmx.net \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.