Hi Dave!
On 08/05/2015 10:47 AM, Dave Chinner wrote:
make realclean also removes the .census file, so it appears that
the debian package build has a dependency on it. Still, that's a
side issue, because we still don't exactly what is causing the
configure script to fail.
Right. The immediate reason is because config.guess and config.sub are not
being updated. Once they are updated, configure will not fail. When I copy them,
manually, from /usr/share/libtool/config/, the build does not fail.
You seem to be talking about 2 different tarballs here. The
tarballs I release most definitely have a configure script in them:
$ tar tfv xfsprogs-4.2.0-rc1.tar.gz |grep configure
-rw-r--r-- dave/dave 3098 2015-08-04 11:16 xfsprogs-4.2.0-rc1/configure.ac
-rwxr-xr-x dave/dave 469084 2015-08-04 14:25 xfsprogs-4.2.0-rc1/configure
So I don't know where you are getting xfsprogs tarballs without
configure scripts from.
My apologies, it was a confusion of my part. I was looking at the git tree.
The tarball does come with configure. But the config.{guess,sub} that come with
it are up-to-date, differently of what comes with the debian src package.
I generated a diff from them, which is attached.
Also, the version I have here is not 4.2.0-rc1, it is the one found at the git
repository I mentioned. Is that not correct?
To clear up any confusion, can you please explain exactly what you
are building (step by step for the dummies in the audience like me)
so we all understand exactly what context the build is failing in?
Ok. Just clarifying that what actually fails is the debian package, exclusively.
The ones found in xfs.org (actually oss.sgi.com/xfs) build flawlessly.
Originally I used sbuild, but manually this is what I do:
# apt-get source xfsprogs
# cd xfsprogs-3.2.4/
# apt-get build-dep xfsprogs
...
# dpkg-buildpackage
I am attaching the build log because it is a bit long.
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.
Did you actually try it?
Yes, I changed that line 1315 in /usr/share/aclocal/libtool.m4 to look the same
as you showed, but the build failed anyway.
Sure, it may not be the reason that it builds correctly on Darrick's
machine, but the fact is that Darricks' environment successfully
builds packages from the official xfsprogs tarballs without
problems and yours doesn't. The above change is the only thing that
is non-standard in Darrick's environment, so it's an obvious change
to try even if it makes no sense to you.
I understand that.
A correction though: mine builds from the official xfsprogs source or tarballs
without problems too.
It is the Debian source package that fails, exclusively.
And it still doesn't change the situation: we can't fix the problem
until we understand what is causing it....
What is causing it is: the old files config.guess and config.sub in the source
package. Whether shipping updated ones or not shipping the configure file would
be the quick solution to this. Again, it is an exclusive problem with the
Debian package.
I am curious about something I have just noticed (while writing this e-mail).
Running apt-get source xfsprogs gets a tarball xfsprogs_3.2.4.tar.gz
Shouldn't it be the exact same file I get from:
http://ftp.br.debian.org/debian/pool/main/x/xfsprogs/xfsprogs_3.2.4.tar.gz
Because they differ. And the latter does not fail at all.
I am sorry for any confusion I might be causing :)
Thanks and regards.
--
Fernando Seiti Furusato
IBM Linux Technology Center
xfs_build.log
Description: Text Data
config_guess_sub.diff
Description: Text Data
|