xfsprogs fails to build on debian ppc64el
Hi,
xfsprogs 3.2.4 fails to build on ppc64el, see log below or full build log https://buildd.debian.org/status/fetch.php?pkg=xfsprogs&arch=ppc64el&ver=3.2.4&stamp=1438318450
(xfsprogs 3.2.3 already failed with the same error)
What is the reason for this, libtool to old?
This potentially prevents the migration of the package to testing, which leaves CVE-2012-2150 open in testing on all arches.
Cheers,
Daniel
== dpkg-buildpackage: configure
test -f debian/rules
AUTOHEADER=/bin/true dh_autoreconf
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.before
autoreconf -f -ilibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.afterexport DEBUG=-DNDEBUG DISTRIBUTION=debian INSTALL_USER=root INSTALL_GROUP=root LOCAL_CONFIGURE_OPTIONS="--enable-readline=yes --enable-blkid=yes" ; /usr/bin/make include/platform_defs.h make[1]: Entering directory '/«PKGBUILDDIR»'
./configure $LOCAL_CONFIGURE_OPTIONS
./config.guess: unable to guess system type
This script, last modified 2012-02-10, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
If the version you run (./config.guess) is already up to date, please send the following data and any information you think might be pertinent to <[email protected]> in order to provide the needed information to handle your system.
config.guess timestamp = 2012-02-10
uname -m = ppc64le
uname -r = 3.16.0-4-powerpc64le
uname -s = Linux
uname -v = #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
/usr/bin/uname -p =/bin/uname -X =
hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel =
/usr/convex/getsysinfo =
UNAME_MACHINE = ppc64leUNAME_RELEASE = 3.16.0-4-powerpc64leUNAME_SYSTEM = LinuxUNAME_VERSION = #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
configure: error: cannot guess build type; you must specify one
make[1]: *** [include/builddefs] Error 1
checking build system type... Makefile:89: recipe for target 'include/builddefs' failed make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [.census] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2 debian/rules:36: recipe for target '.census' failed
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
That error is common when configure is generated using out-of-date config.guess and config.sub.
The ones that come with the package are, in fact, old.
This package used to run dh_autotools-dev_updateconfig and dh_autotools-dev_restoreconfig, which worked because it only updates those files.
They were replaced by dh_autoreconf and dh_autoreconf_clean, which should update them, but does not run flawlessly.
I think something is wrong with the m4 macros but I am not sure what. There are errors when running dh_autoreconf alone.
# dh_autoreconf libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoheader: warning: missing template: HAVE_UMODE_T autoheader: Use AC_DEFINE([HAVE_UMODE_T], [], [Description]) autoheader: warning: missing template: HAVE___PSINT_T autoheader: warning: missing template: HAVE___PSUNSIGNED_T autoheader: warning: missing template: HAVE___U32 autoreconf: /usr/bin/autoheader failed with exit status: 1 dh_autoreconf: autoreconf -f -i returned exit code 1
I will keep working on it, but all I will be able to do if I get to a conclusion is send a patch here.
Thus it will have to be dealt with by the maintainers anyway.
Regards.
Signature · 7 lines
Fernando Seiti Furusato IBM Linux Technology Center _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 3 lines · Fernando Seiti Furusato
That error is common when configure is generated using out-of-date config.guess and config.sub.
The ones that come with the package are, in fact, old.
config.sub and config.guess are generated by the build, we don't ship them directly from the git repository. Perhaps you are building from a release tarball rather than from a clean git repository working area? Can you confirm this is the case?
If so, can you remove the configure, config.sub and config.guess files and see if you get the same problem?
Quoted 27 lines
This package used to run dh_autotools-dev_updateconfig and dh_autotools-dev_restoreconfig, which worked because it only updates those files.
They were replaced by
dh_autoreconfanddh_autoreconf_clean, which should update them, but does not run flawlessly.
I think something is wrong with the m4 macros but I am not sure what. There are errors when runningdh_autoreconfalone.# dh_autoreconf libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoheader: warning: missing template: HAVE_UMODE_T autoheader: Use AC_DEFINE([HAVE_UMODE_T], [], [Description]) autoheader: warning: missing template: HAVE___PSINT_T autoheader: warning: missing template: HAVE___PSUNSIGNED_T autoheader: warning: missing template: HAVE___U32 autoreconf: /usr/bin/autoheader failed with exit status: 1 dh_autoreconf: autoreconf -f -i returned exit code 1
Quoted 3 lines
I will keep working on it, but all I will be able to do if I get to a conclusion is send a patch here.
Thus it will have to be dealt with by the maintainers anyway.
The XFS list is cc'd on the bug, so the upstream maintainers are watching and will see the patch when you post it. ;)
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
Quoted 4 lines
Am 02.08.2015 um 00:52 schrieb Dave Chinner <[email protected]>:
On Fri, Jul 31, 2015 at 06:57:35PM -0300, Fernando Seiti Furusato wrote:
Quoted 9 lines
Quoted 3 lines
That error is common when configure is generated using out-of-date config.guess and config.sub.
The ones that come with the package are, in fact, old.config.sub and config.guess are generated by the build, we don't ship them directly from the git repository. Perhaps you are building from a release tarball rather than from a clean git repository working area? Can you confirm this is the case?
Just some observations from my side:
Extracting the released tarball over a clean xfsprogs git repo and removing the .gitignore file, then git status reveals:
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitcensus aclocal.m4 config.guess config.sub configure install-sh ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 m4/ltversion.m4 m4/lt~obsolete.m4 po/xfsprogs.pot
Looks like there are a lot of untracked file. Is this intentional, to have potentially auto-generated but un-versioned files in a release tarball?
It gets even more interesting, comparing debian source vs official release:
http://http.debian.net/debian/pool/main/x/xfsprogs/xfsprogs_3.2.4.tar.gz <http://http.debian.net/debian/pool/main/x/xfsprogs/xfsprogs_3.2.4.tar.gz>
ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-3.2.4.tar.gz <ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-3.2.4.tar.gz>
There are differences in the following files:
modified: aclocal.m4 modified: config.guess modified: config.sub modified: configure modified: ltmain.sh modified: m4/libtool.m4 modified: po/xfsprogs.pot
So, imho the debian source tarball also doesn’t look clean, neither against the release tarball nor against a clean git checkout.
Just my 2 cents, maybe that helps someone to solve this.
Cheers,
Daniel
Quoted 34 lines
If so, can you remove the configure, config.sub and config.guess files and see if you get the same problem?
Quoted 27 lines
This package used to run dh_autotools-dev_updateconfig and dh_autotools-dev_restoreconfig, which worked because it only updates those files.
They were replaced by
dh_autoreconfanddh_autoreconf_clean, which should update them, but does not run flawlessly.
I think something is wrong with the m4 macros but I am not sure what. There are errors when runningdh_autoreconfalone.# dh_autoreconf libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoheader: warning: missing template: HAVE_UMODE_T autoheader: Use AC_DEFINE([HAVE_UMODE_T], [], [Description]) autoheader: warning: missing template: HAVE___PSINT_T autoheader: warning: missing template: HAVE___PSUNSIGNED_T autoheader: warning: missing template: HAVE___U32 autoreconf: /usr/bin/autoheader failed with exit status: 1 dh_autoreconf: autoreconf -f -i returned exit code 1Quoted 3 lines
I will keep working on it, but all I will be able to do if I get to a conclusion is send a patch here.
Thus it will have to be dealt with by the maintainers anyway.
Quoted 14 lines
The XFS list is cc'd on the bug, so the upstream maintainers are watching and will see the patch when you post it. ;)
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Dave Chinner
Reviewed-by Mike FrysingerRe: Bug#793495: xfsprogs fails to build on debian ppc64el
Quoted 37 lines · Daniel Bast
Quoted 5 lines
Am 02.08.2015 um 00:52 schrieb Dave Chinner
<[email protected]>:On Fri, Jul 31, 2015 at 06:57:35PM -0300, Fernando Seiti Furusato wrote:
Quoted 9 lines
Quoted 3 lines
That error is common when configure is generated using out-of-date config.guess and config.sub. The ones that come with the package are, in fact, old.
config.sub and config.guess are generated by the build, we don't ship them directly from the git repository. Perhaps you are building from a release tarball rather than from a clean git repository working area? Can you confirm this is the case?
Just some observations from my side:
Extracting the released tarball over a clean xfsprogs git repo and removing the .gitignore file, then git status reveals:
Untracked files:
(use "git add <file>..." to include in what will be committed).gitcensus aclocal.m4 config.guess config.sub configure install-sh ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 m4/ltversion.m4 m4/lt~obsolete.m4 po/xfsprogs.pot
Quoted 3 lines
Looks like there are a lot of untracked file. Is this intentional, to have potentially auto-generated but un-versioned files in a release tarball?
Goes back to 2009:
commit 1eb10ccb85261931d5401adbff11acd2dbc5bf63
Author: Christoph Hellwig <[email protected]> Date: Wed Apr 29 15:32:28 2009 +0200
keep autoconf-generated files over make distclean
We do want to ship the autoconf-generated files over make distclean and pick them up in Makepkgs so that a user compiling the program doesn't require autoconf.
For that split up make distclean from make realclean and exclude the files we want to keep form the former.
To make this easier to maintain adher to stricter rules of use for CONFIGURE and LDIRT. CONFIGURE now includes all generated files from autoconf (or for it like our copied install-sh) and gets only removed on make realclean, but added to LSRCFILES so that Makepkgs can pick it up. Everything else than needs to be removed on a realclean gets assigned to LDIRT.
Also split up the configure rule into one to generate the configure script and one to run it.
So we've been doing this with release tarballs for more than 6 years - I checked and found these files in the tarballs back to 3.0.1. The above commit is the last commit prior to the release of 3.0.1...
Nowdays, the generated files in the 3.2.4 tarball created via a 'make dist' rule. I run that on an up to date debian unstable box with autoconfig 2.69 installed to generate the files, so the question I have is this: why is an up-to-date build box generating "out of date" configure/m4 scripts? What, exactly, is out of date, and how do I ensure that the pre-build config files are correctly up-to-date?
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
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.
Curiously, running dpkg-buildpackage twice, causes configure file to be deleted, and the build completes without errors.
So, answering to your question:
Quoted 7 lines
Nowdays, the generated files in the 3.2.4 tarball created via a 'make dist' rule. I run that on an up to date debian unstable box with autoconfig 2.69 installed to generate the files, so the question I have is this: why is an up-to-date build box generating "out of date" configure/m4 scripts? What, exactly, is out of date, and how do I ensure that the pre-build config files are correctly up-to-date?
The configure file comes shipped with the debian package, so that specific file
is not re-generated and is always out of date.
By the looks of the Makefile, there is no need to include autoreconf or autotools-dev in debian/rules, but to force make distclean to rm configure.
Attached is a patch that summarizes that, but for some reason it does not work when running with parallel jobs enabled. But you can get the idea :)
Regards.
Signature · 2 lines
Fernando Seiti Furusato IBM Linux Technology Center
debian/changelog +7 -0
@@ -1,3 +1,10 @@ +xfsprogs (3.2.4ppc64el1) UNRELEASED; urgency=medium + + * debian/rules: removed usage of dh_autoreconf since it is not necessary. + * Makefile: change distclean target to remove configure every time. + + -- Fernando Seiti Furusato <[email protected]> Tue, 04 Aug 2015 11:07:01 -0400 + xfsprogs (3.2.4) unstable; urgency=low * New upstream release
debian/rules +0 -2
@@ -35,7 +35,6 @@ .census: @echo "== dpkg-buildpackage: configure" 1>&2 $(checkdir) - AUTOHEADER=/bin/true dh_autoreconf $(options) $(MAKE) include/platform_defs.h touch .census
@@ -58,7 +57,6 @@ $(MAKE) distclean -rm -rf $(dirme) $(dirdev) $(dirdi) -rm -f debian/*substvars debian/files* debian/*.debhelper - dh_autoreconf_clean dh_clean binary-indep:
Makefile +1 -1
@@ -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
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
Quoted 15 lines · Fernando Seiti Furusato
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
Makefilewas made.In
Makefile, @row 80:
LIBTOOLIZE_INSTALL=libtoolize -n -i >/dev/null 2>/dev/null && echo -iconfigure:
libtoolize -c $(LIBTOOLIZE_INSTALL) -f
cpinclude/install-sh.
aclocal -I m4
autoconf
Quoted 5 lines
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.
....
Makefile line 122
Quoted 12 lines
diff -Nru xfsprogs-3.2.4/Makefile xfsprogs-3.2.4ppc64el1/Makefile
Makefile +1
-1@@ -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:
Quoted 4 lines
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.69Which 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:
libtool.m4 2015-07-31 13:48:23.375432372 -0700 renamed from libtool.m4 2014-02-11 04:58:49.000000000 -0800 +1 -1
@@ -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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
Quoted 6 lines · Dave Chinner
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
Quoted 2 lines
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.
Quoted 23 lines
Quoted 5 lines
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.69Which 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:libtool.m4 2015-07-31 13:48:23.375432372 -0700 renamed from libtool.m4 2014-02-11 04:58:49.000000000 -0800 +1
-1@@ -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
Quoted 2 lines
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:
Quoted 1 line
Quoted 1 line
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.
Signature · 7 lines
Fernando Seiti Furusato IBM Linux Technology Center _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
Quoted 11 lines · Fernando Seiti Furusato
Quoted 6 lines · Dave Chinner
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.
Quoted 8 lines
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
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.
Quoted 7 lines
Quoted 2 lines
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
Makefilegenerates it and runs libtoolize -c -i which updates the configuration files needed.
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.
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?
Quoted 22 lines
Quoted 22 lines
Quoted 4 lines
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.69Which 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:libtool.m4 2015-07-31 13:48:23.375432372 -0700 renamed from libtool.m4 2014-02-11 04:58:49.000000000 -0800 +1
-1@@ -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
Quoted 7 lines
Quoted 2 lines
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:
Quoted 1 line
Quoted 1 line
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?
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.
And it still doesn't change the situation: we can't fix the problem until we understand what is causing it....
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
Hi Dave!
Quoted 4 lines · Dave Chinner
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.
Quoted 9 lines
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(quoted diff) +0
-2-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/configureSo 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?
Quoted 5 lines
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.
Quoted 6 lines
Quoted 4 lines
Actually powerpc*-*linux* covers the triplet for ppc64el, as seen in:
Quoted 1 line
Quoted 1 line
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.
Quoted 7 lines
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.
Quoted 3 lines
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.
Signature · 2 lines
Fernando Seiti Furusato IBM Linux Technology Center
dpkg-buildpackage: source package xfsprogs
dpkg-buildpackage: source version 3.2.4
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Nathan Scott <[email protected]>
dpkg-source --before-build xfsprogs-3.2.4
dpkg-buildpackage: host architecture ppc64el
debian/rules clean
== dpkg-buildpackage: clean
test -f debian/rules
rm -f built .census mkfs/mkfs.xfs-xfsprogs-udeb/usr/bin/make distclean
make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4'
make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4'
rm -rf debian/xfsprogs debian/xfslibs-dev debian/xfsprogs-udeb
rm -f debian/*substvars debian/files* debian/*.debhelperdh_autoreconf_cleandh_clean
rm -f debian/xfsprogs.substvars
rm -f debian/xfsprogs.*.debhelper
rm -rf debian/xfsprogs/
rm -f debian/xfslibs-dev.substvars
rm -f debian/xfslibs-dev.*.debhelper
rm -rf debian/xfslibs-dev/
rm -f debian/xfsprogs-udeb.substvars
rm -f debian/xfsprogs-udeb.*.debhelper
rm -rf debian/xfsprogs-udeb/
rm -f debian/*.debhelper.log
rm -f debian/files
find . \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path .\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \) \)
dpkg-source -b xfsprogs-3.2.4
dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1)
dpkg-source: info: using source format `1.0'
dpkg-source: info: building xfsprogs in xfsprogs_3.2.4.tar.gz
dpkg-source: info: building xfsprogs in xfsprogs_3.2.4.dsc
debian/rules build
test -f debian/rules
== dpkg-buildpackage: installer
if [ ! -f mkfs/mkfs.xfs-xfsprogs-udeb ]; then \ export DEBUG=-DNDEBUG DISTRIBUTION=debian INSTALL_USER=root INSTALL_GROUP=root LOCAL_CONFIGURE_OPTIONS="--enable-readline=yes --enable-blkid=yes" ; export OPTIMIZER=-Os LOCAL_CONFIGURE_OPTIONS="--enable-gettext=no" ; /usr/bin/make include/platform_defs.h; \ for dir in include libxfs libdisk mkfs; do \ /usr/bin/make -C $dir; \ done; \ mv mkfs/mkfs.xfs mkfs/mkfs.xfs-xfsprogs-udeb; \ /usr/bin/make distclean; \
fi
make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4' ./configure $LOCAL_CONFIGURE_OPTIONS
checking build system type... ./config.guess: unable to guess system type
This script, last modified 2012-02-10, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
If the version you run (./config.guess) is already up to date, please send the following data and any information you think might be pertinent to <[email protected]> in order to provide the needed information to handle your system.
config.guess timestamp = 2012-02-10
uname -m = ppc64le
uname -r = 3.16.0-4-powerpc64le
uname -s = Linux
uname -v = #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
/usr/bin/uname -p =/bin/uname -X =
hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel =
/usr/convex/getsysinfo =
UNAME_MACHINE = ppc64leUNAME_RELEASE = 3.16.0-4-powerpc64leUNAME_SYSTEM = LinuxUNAME_VERSION = #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
configure: error: cannot guess build type; you must specify one Makefile:89: recipe for target 'include/builddefs' failed make[1]: *** [include/builddefs] Error 1
make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4' make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4/include' Makefile:19: ../include/builddefs: No such file or directory make[1]: *** No rule to make target '../include/builddefs'. Stop. make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4/include' make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4/libxfs' Makefile:6: ../include/builddefs: No such file or directory make[1]: *** No rule to make target '../include/builddefs'. Stop. make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4/libxfs' make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4/libdisk' Makefile:6: ../include/builddefs: No such file or directory make[1]: *** No rule to make target '../include/builddefs'. Stop. make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4/libdisk' make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4/mkfs' Makefile:6: ../include/builddefs: No such file or directory make[1]: *** No rule to make target '../include/builddefs'. Stop. make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4/mkfs'
mv: cannot stat ‘mkfs/mkfs.xfs’: No such file or directory make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4' make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4' == dpkg-buildpackage: configure
test -f debian/rules
AUTOHEADER=/bin/true dh_autoreconf
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.before
autoreconf -f -ilibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.afterexport DEBUG=-DNDEBUG DISTRIBUTION=debian INSTALL_USER=root INSTALL_GROUP=root LOCAL_CONFIGURE_OPTIONS="--enable-readline=yes --enable-blkid=yes" ; /usr/bin/make include/platform_defs.h make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4'
./configure $LOCAL_CONFIGURE_OPTIONS
checking build system type... ./config.guess: unable to guess system type
This script, last modified 2012-02-10, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
If the version you run (./config.guess) is already up to date, please send the following data and any information you think might be pertinent to <[email protected]> in order to provide the needed information to handle your system.
config.guess timestamp = 2012-02-10
uname -m = ppc64le
uname -r = 3.16.0-4-powerpc64le
uname -s = Linux
uname -v = #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
/usr/bin/uname -p =/bin/uname -X =
hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = /usr/bin/oslevel =
/usr/convex/getsysinfo =
UNAME_MACHINE = ppc64leUNAME_RELEASE = 3.16.0-4-powerpc64leUNAME_SYSTEM = LinuxUNAME_VERSION = #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
configure: error: cannot guess build type; you must specify one 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
dpkg-buildpackage: error: debian/rules build gave error exit status 2
config.guess +118 -228
@@ -1,14 +1,12 @@ #! /bin/sh # Attempt to guess a canonical system name. -# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, -# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, -# 2011, 2012 Free Software Foundation, Inc. +# Copyright 1992-2014 Free Software Foundation, Inc. -timestamp='2012-02-10' +timestamp='2014-03-23' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or +# the Free Software Foundation; either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, but
@@ -22,19 +20,17 @@ timestamp='2012-02-10' # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under -# the same distribution terms that you use for the rest of that program. - - -# Originally written by Per Bothner. Please send patches (context -# diff format) to <[email protected]> and include a ChangeLog -# entry. +# the same distribution terms that you use for the rest of that +# program. This Exception is an additional permission under section 7 +# of the GNU General Public License, version 3 ("GPLv3"). # -# This script attempts to guess a canonical system name similar to -# config.sub. If it succeeds, it prints the system name on stdout, and -# exits with 0. Otherwise, it exits with 1. +# Originally written by Per Bothner. # # You can get the latest version of this script from: # http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD +# +# Please send patches with a ChangeLog entry to [email protected]. + me=`echo "$0" | sed -e 's,.*/,,'`
@@ -54,9 +50,7 @@ version="\ GNU config.guess ($timestamp) Originally written by Per Bothner. -Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, -2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 -Free Software Foundation, Inc. +Copyright 1992-2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -138,6 +132,27 @@ UNAME_RELEASE=`(uname -r) 2>/dev/null` | UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown +case "${UNAME_SYSTEM}" in +Linux|GNU|GNU/*) + # If the system lacks a compiler, then just pick glibc. + # We could probably try harder. + LIBC=gnu + + eval $set_cc_for_build + cat <<-EOF > $dummy.c + #include <features.h> + #if defined(__UCLIBC__) + LIBC=uclibc + #elif defined(__dietlibc__) + LIBC=dietlibc + #else + LIBC=gnu + #endif + EOF + eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^LIBC' | sed 's, ,,g'` + ;; +esac + # Note: order is significant - the case branches are not exclusive. case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
@@ -200,6 +215,10 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$ # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used. echo "${machine}-${os}${release}" exit ;; + *:Bitrig:*:*) + UNAME_MACHINE_ARCH=`arch | sed 's/Bitrig.//'` + echo ${UNAME_MACHINE_ARCH}-unknown-bitrig${UNAME_RELEASE} + exit ;; *:OpenBSD:*:*) UNAME_MACHINE_ARCH=`arch | sed 's/OpenBSD.//'` echo ${UNAME_MACHINE_ARCH}-unknown-openbsd${UNAME_RELEASE}
@@ -302,7 +321,7 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$ arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*) echo arm-acorn-riscix${UNAME_RELEASE} exit ;; - arm:riscos:*:*|arm:RISCOS:*:*) + arm*:riscos:*:*|arm*:RISCOS:*:*) echo arm-unknown-riscos exit ;; SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*)
@@ -801,10 +820,13 @@ EOF i*:CYGWIN*:*) echo ${UNAME_MACHINE}-pc-cygwin exit ;; + *:MINGW64*:*) + echo ${UNAME_MACHINE}-pc-mingw64 + exit ;; *:MINGW*:*) echo ${UNAME_MACHINE}-pc-mingw32 exit ;; - i*:MSYS*:*) + *:MSYS*:*) echo ${UNAME_MACHINE}-pc-msys exit ;; i*:windows32*:*)
@@ -852,21 +874,21 @@ EOF exit ;; *:GNU:*:*) # the GNU system - echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'` + echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-${LIBC}`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'` exit ;; *:GNU/*:*:*) # other systems with GNU libc and userland - echo ${UNAME_MACHINE}-unknown-`echo ${UNAME_SYSTEM} | sed 's,^[^/]*/,,' | tr '[A-Z]' '[a-z]'``echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`-gnu + echo ${UNAME_MACHINE}-unknown-`echo ${UNAME_SYSTEM} | sed 's,^[^/]*/,,' | tr '[A-Z]' '[a-z]'``echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`-${LIBC} exit ;; i*86:Minix:*:*) echo ${UNAME_MACHINE}-pc-minix exit ;; aarch64:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; aarch64_be:Linux:*:*) UNAME_MACHINE=aarch64_be - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; alpha:Linux:*:*) case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' < /proc/cpuinfo` in
@@ -879,59 +901,54 @@ EOF EV68*) UNAME_MACHINE=alphaev68 ;; esac objdump --private-headers /bin/sh | grep -q ld.so.1 - if test "$?" = 0 ; then LIBC="libc1" ; else LIBC="" ; fi - echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC} + if test "$?" = 0 ; then LIBC="gnulibc1" ; fi + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} + exit ;; + arc:Linux:*:* | arceb:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; arm*:Linux:*:*) eval $set_cc_for_build if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \ | grep -q __ARM_EABI__ then - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} else if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \ | grep -q __ARM_PCS_VFP then - echo ${UNAME_MACHINE}-unknown-linux-gnueabi + echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi else - echo ${UNAME_MACHINE}-unknown-linux-gnueabihf + echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf fi fi exit ;; avr32*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; cris:Linux:*:*) - echo ${UNAME_MACHINE}-axis-linux-gnu + echo ${UNAME_MACHINE}-axis-linux-${LIBC} exit ;; crisv32:Linux:*:*) - echo ${UNAME_MACHINE}-axis-linux-gnu + echo ${UNAME_MACHINE}-axis-linux-${LIBC} exit ;; frv:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; hexagon:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; i*86:Linux:*:*) - LIBC=gnu - eval $set_cc_for_build - sed 's/^ //' << EOF >$dummy.c - #ifdef __dietlibc__ - LIBC=dietlibc - #endif -EOF - eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^LIBC'` - echo "${UNAME_MACHINE}-pc-linux-${LIBC}" + echo ${UNAME_MACHINE}-pc-linux-${LIBC} exit ;; ia64:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; m32r*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; m68*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; mips:Linux:*:* | mips64:Linux:*:*) eval $set_cc_for_build
@@ -950,54 +967,63 @@ EOF #endif EOF eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` - test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } + test x"${CPU}" != x && { echo "${CPU}-unknown-linux-${LIBC}"; exit; } ;; - or32:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + openrisc*:Linux:*:*) + echo or1k-unknown-linux-${LIBC} + exit ;; + or32:Linux:*:* | or1k*:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; padre:Linux:*:*) - echo sparc-unknown-linux-gnu + echo sparc-unknown-linux-${LIBC} exit ;; parisc64:Linux:*:* | hppa64:Linux:*:*) - echo hppa64-unknown-linux-gnu + echo hppa64-unknown-linux-${LIBC} exit ;; parisc:Linux:*:* | hppa:Linux:*:*) # Look for CPU level case `grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2` in - PA7*) echo hppa1.1-unknown-linux-gnu ;; - PA8*) echo hppa2.0-unknown-linux-gnu ;; - *) echo hppa-unknown-linux-gnu ;; + PA7*) echo hppa1.1-unknown-linux-${LIBC} ;; + PA8*) echo hppa2.0-unknown-linux-${LIBC} ;; + *) echo hppa-unknown-linux-${LIBC} ;; esac exit ;; ppc64:Linux:*:*) - echo powerpc64-unknown-linux-gnu + echo powerpc64-unknown-linux-${LIBC} exit ;; ppc:Linux:*:*) - echo powerpc-unknown-linux-gnu + echo powerpc-unknown-linux-${LIBC} + exit ;; + ppc64le:Linux:*:*) + echo powerpc64le-unknown-linux-${LIBC} + exit ;; + ppcle:Linux:*:*) + echo powerpcle-unknown-linux-${LIBC} exit ;; s390:Linux:*:* | s390x:Linux:*:*) - echo ${UNAME_MACHINE}-ibm-linux + echo ${UNAME_MACHINE}-ibm-linux-${LIBC} exit ;; sh64*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; sh*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; sparc:Linux:*:* | sparc64:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; tile*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; vax:Linux:*:*) - echo ${UNAME_MACHINE}-dec-linux-gnu + echo ${UNAME_MACHINE}-dec-linux-${LIBC} exit ;; x86_64:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; xtensa*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; i*86:DYNIX/ptx:4*:*) # ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.
@@ -1201,6 +1227,9 @@ EOF BePC:Haiku:*:*) # Haiku running on Intel PC compatible. echo i586-pc-haiku exit ;; + x86_64:Haiku:*:*) + echo x86_64-unknown-haiku + exit ;; SX-4:SUPER-UX:*:*) echo sx4-nec-superux${UNAME_RELEASE} exit ;;
@@ -1227,19 +1256,31 @@ EOF exit ;; *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown - case $UNAME_PROCESSOR in - i386) - eval $set_cc_for_build - if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then - if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \ - (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ - grep IS_64BIT_ARCH >/dev/null - then - UNAME_PROCESSOR="x86_64" - fi - fi ;; - unknown) UNAME_PROCESSOR=powerpc ;; - esac + eval $set_cc_for_build + if test "$UNAME_PROCESSOR" = unknown ; then + UNAME_PROCESSOR=powerpc + fi + if test `echo "$UNAME_RELEASE" | sed -e 's/\..*//'` -le 10 ; then + if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then + if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \ + (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ + grep IS_64BIT_ARCH >/dev/null + then + case $UNAME_PROCESSOR in + i386) UNAME_PROCESSOR=x86_64 ;; + powerpc) UNAME_PROCESSOR=powerpc64 ;; + esac + fi + fi + elif test "$UNAME_PROCESSOR" = i386 ; then + # Avoid executing cc on OS X 10.9, as it ships with a stub + # that puts up a graphical alert prompting to install + # developer tools. Any system running Mac OS X 10.7 or + # later (Darwin 11 and later) is required to have a 64-bit + # processor. This is not true of the ARM version of Darwin + # that Apple uses in portable devices. + UNAME_PROCESSOR=x86_64 + fi echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} exit ;; *:procnto*:*:* | *:QNX:[0123456789]*:*)
@@ -1256,7 +1297,7 @@ EOF NEO-?:NONSTOP_KERNEL:*:*) echo neo-tandem-nsk${UNAME_RELEASE} exit ;; - NSE-?:NONSTOP_KERNEL:*:*) + NSE-*:NONSTOP_KERNEL:*:*) echo nse-tandem-nsk${UNAME_RELEASE} exit ;; NSR-?:NONSTOP_KERNEL:*:*)
@@ -1330,157 +1371,6 @@ EOF exit ;; esac -#echo '(No uname command or uname output not recognized.)' 1>&2 -#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2 - -eval $set_cc_for_build -cat >$dummy.c <<EOF -#ifdef _SEQUENT_ -# include <sys/types.h> -# include <sys/utsname.h> -#endif -main () -{ -#if defined (sony) -#if defined (MIPSEB) - /* BFD wants "bsd" instead of "newsos". Perhaps BFD should be changed, - I don't know.... */ - printf ("mips-sony-bsd\n"); exit (0); -#else -#include <sys/param.h> - printf ("m68k-sony-newsos%s\n", -#ifdef NEWSOS4 - "4" -#else - "" -#endif - ); exit (0); -#endif -#endif - -#if defined (__arm) && defined (__acorn) && defined (__unix) - printf ("arm-acorn-riscix\n"); exit (0); -#endif - -#if defined (hp300) && !defined (hpux) - printf ("m68k-hp-bsd\n"); exit (0); -#endif - -#if defined (NeXT) -#if !defined (__ARCHITECTURE__) -#define __ARCHITECTURE__ "m68k" -#endif - int version; - version=`(hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null`; - if (version < 4) - printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version); - else - printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version); - exit (0); -#endif - -#if defined (MULTIMAX) || defined (n16) -#if defined (UMAXV) - printf ("ns32k-encore-sysv\n"); exit (0); -#else -#if defined (CMU) - printf ("ns32k-encore-mach\n"); exit (0); -#else - printf ("ns32k-encore-bsd\n"); exit (0); -#endif -#endif -#endif - -#if defined (__386BSD__) - printf ("i386-pc-bsd\n"); exit (0); -#endif - -#if defined (sequent) -#if defined (i386) - printf ("i386-sequent-dynix\n"); exit (0); -#endif -#if defined (ns32000) - printf ("ns32k-sequent-dynix\n"); exit (0); -#endif -#endif - -#if defined (_SEQUENT_) - struct utsname un; - - uname(&un); - - if (strncmp(un.version, "V2", 2) == 0) { - printf ("i386-sequent-ptx2\n"); exit (0); - } - if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */ - printf ("i386-sequent-ptx1\n"); exit (0); - } - printf ("i386-sequent-ptx\n"); exit (0); - -#endif - -#if defined (vax) -# if !defined (ultrix) -# include <sys/param.h> -# if defined (BSD) -# if BSD == 43 - printf ("vax-dec-bsd4.3\n"); exit (0); -# else -# if BSD == 199006 - printf ("vax-dec-bsd4.3reno\n"); exit (0); -# else - printf ("vax-dec-bsd\n"); exit (0); -# endif -# endif -# else - printf ("vax-dec-bsd\n"); exit (0); -# endif -# else - printf ("vax-dec-ultrix\n"); exit (0); -# endif -#endif - -#if defined (alliant) && defined (i860) - printf ("i860-alliant-bsd\n"); exit (0); -#endif - - exit (1); -} -EOF - -$CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null && SYSTEM_NAME=`$dummy` && - { echo "$SYSTEM_NAME"; exit; } - -# Apollos put the system type in the environment. - -test -d /usr/apollo && { echo ${ISP}-apollo-${SYSTYPE}; exit; } - -# Convex versions that predate uname can use getsysinfo(1) - -if [ -x /usr/convex/getsysinfo ] -then - case `getsysinfo -f cpu_type` in - c1*) - echo c1-convex-bsd - exit ;; - c2*) - if getsysinfo -f scalar_acc - then echo c32-convex-bsd - else echo c2-convex-bsd - fi - exit ;; - c34*) - echo c34-convex-bsd - exit ;; - c38*) - echo c38-convex-bsd - exit ;; - c4*) - echo c4-convex-bsd - exit ;; - esac -fi - cat >&2 <<EOF $0: unable to guess system type
config.sub +67 -50
292 lines not on this page · raw message
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
Quoted 19 lines · Fernando Seiti Furusato
Hi Dave!
Quoted 4 lines · Dave Chinner
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.Quoted 7 lines
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(quoted diff) +0
-2-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
Quoted 8 lines
Quoted 2 lines
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?
I released 4.2.0-rc1 to the dev tree on kernel.org. I didn't update the tree on oss.sgi.com or make an official release tarball because it's a developer pre-release. And there's a couple of things under discussion that that might require a rebase of the tree, so that's another reason for not making an "official" release.
....
Quoted 3 lines
A correction though: mine builds from the official xfsprogs source or tarballs without problems too.
It is the Debian source package that fails, exclusively.
Ok, that clears up the confusion. Thanks for explaining what is happening to the dummy in the audience (me).
Quoted 5 lines
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.
No idea - that's definitely a distro issue ;)
Quoted 5 lines
make[1]: Entering directory '
/home/xfsprogs/xfsprogs-3.2.4' ./configure $LOCAL_CONFIGURE_OPTIONS
checking build system type... ./config.guess: unable to guess system typeThis script, last modified 2012-02-10, has failed to recognize
This is what I found about an hour before reading this email. On #xfs:
[06/08/15 09:32] <dchinner_> now that "last modified <$timestamp>" is important [06/08/15 09:33] <dchinner_> because that tells us what version was used to generate the script [06/08/15 09:34] <dchinner_> in the version shipped in the 3.2.4 tarball, it is:
[06/08/15 09:34] <dchinner_> timestamp='2014-03-23'
[06/08/15 09:34] <dchinner_> and it clearly has entries for ppc64le in it
Quoted 4 lines
ppc64:Linux:*:*)config.guess +1
-1- echo powerpc64-unknown-linux-gnu + echo powerpc64-unknown-linux-${LIBC} exit ;;
config.guess EOF · line 1003
Quoted 10 lines
config.guess +7
-1ppc:Linux:*:*) - echo powerpc-unknown-linux-gnu + echo powerpc-unknown-linux-${LIBC} + exit ;; + ppc64le:Linux:*:*) + echo powerpc64le-unknown-linux-${LIBC} + exit ;; + ppcle:Linux:*:*) + echo powerpcle-unknown-linux-${LIBC} exit ;;
That hunk shows why it is failing - no ppc64le:Linux match in the old script. Nathan is already looking into it...
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Re: Bug#793495: xfsprogs fails to build on debian ppc64el
----- Original Message -----
Quoted 6 lines · Fernando Seiti Furusato
Quoted 2 lines
[...]
It is the Debian source package that fails, exclusively.[...]
That hunk shows why it is failing - no ppc64le:Linux match in the old script. Nathan is already looking into it...
So, yeah, its definitely got something to do with the local setup here inserting configure-generated files that are dated. I build the .debs from a tagged git repo checkout (without the generated files initially) so they do get inserted locally.
Having re-installed all autoconf-related packages now on that machine, as well as constructing an entirely new unstable VM for builds :P ... the problem has resolved itself and I see config.sub with ppc64le bits too.
I'll do a build and upload (source-unchanged) 3.2.4-1 package to make sure its resolved on the build servers.
Thanks to all for looking into it so closely!
cheers.
--
Nathan
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs