On Mon, Mar 20, 2017 at 02:20:45PM -0700, Gwendal Grignou wrote: > - Request LIBTOOL to be used > - Set topbuildir based on a Makefile variable to call libtool > - Use /usr/local instead of /var for xfstest final location > - Move macros from aclocal.m4 to acinclude.m4, aclocal.m4 is autogenerated. > > TEST=Compile in chromeOS chroot. > TEST=Using a snippet of build-all at https://github.com/tytso/xfstests-bld > After adding config.sub and config.guess with: > cp /usr/share/misc/config.sub /usr/share/misc/config.guess > Verified that compilation of xfstest works: > ver=$(git describe --always --dirty); echo "xfstests $ver ($(git log -1 --pretty=%cD))" > ../xfstests.ver ; > autoheader ; autoconf ; > CFLAGS="$LCF -I$DESTDIR/include -fno-stack-protector" > CPPFLAGS="-I$DESTDIR/include" > LDFLAGS="$LLF -static -L$DESTDIR/lib" > LIBS=-lpthread > ./configure > make -j40 LLDFLAGS=$EXEC_LLDFLAGS LIBTOOL="/usr/bin/libtool --tag=CC" BUILD_VERBOSE=1 > > Signed-off-by: Gwendal Grignou <gwendal@xxxxxxxxxxxx> I'm not an autotools expert, and I really appreciate if someone could help review build/packaging patches, thanks in advance! But I did hit errors when "make" on default fedora25 and RHEL7 hosts (which worked fine prior to this patch), I tried to "fix" them but failed. [root@bootp-73-5-211 fstests]# make autoheader autoconf configure.ac:2: error: possibly undefined macro: AC_CONFIG_MACRO_DIRS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:5: error: possibly undefined macro: AC_PACKAGE_GLOBALS configure.ac:6: error: possibly undefined macro: AC_PACKAGE_UTILITIES configure.ac:43: error: possibly undefined macro: AC_PACKAGE_NEED_UUIDCOMPARE ... Seems AC_CONFIG_MACRO_DIRS is only available starting from autoconf 2.70, but f25 and rhel7 ship autoconf 2.69 by default. After changing AC_CONFIG_MACRO_DIRS to AC_CONFIG_MACRO_DIR, above error is gone, but other errors remain. [root@bootp-73-5-211 fstests]# make autoheader autoconf configure.ac:5: error: possibly undefined macro: AC_PACKAGE_GLOBALS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:6: error: possibly undefined macro: AC_PACKAGE_UTILITIES configure.ac:43: error: possibly undefined macro: AC_PACKAGE_NEED_UUIDCOMPARE ... These macros are all defined in m4/ directory, so seems .m4 files are not included correctly, because aclocal.m4 was not generated automatically. After doing this change to Makefile, I got 'configure' file generated, but configure process failed again, because of missing config.sub file. diff --git a/Makefile b/Makefile index 30d8747..aa8db92 100644 --- a/Makefile +++ b/Makefile @@ -75,7 +75,7 @@ else clean: # if configure hasn't run, nothing to clean endif -configure: configure.ac +configure: aclocal.m4 configure.ac autoheader autoconf @@ -84,7 +84,7 @@ include/builddefs include/config.h: configure --libexecdir=/usr/lib aclocal.m4:: - aclocal --acdir=`pwd`/m4 --output=$@ + aclocal -I`pwd`/m4 --output=$@ depend: include/builddefs $(addsuffix -depend,$(SUBDIRS)) [root@bootp-73-5-211 fstests]# make aclocal -I`pwd`/m4 --output=aclocal.m4 autoheader autoconf ./configure \ --libexecdir=/usr/lib configure: error: cannot run /bin/sh ./config.sub Makefile:83: recipe for target 'include/builddefs' failed make: *** [include/builddefs] Error 127 I noticed that you copied config.sub and config.guess manually to xfstests directory, but this would break existing build process which doesn't expect to do that. And forcing users to do manually copy files to meet build requirements doesn't seem right to me either. Can you please take a look at these issues? Thanks, Eryu -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
