错误:版本不匹配。这是Automake 1.15.1,但定义...来自Automake 1.14.1

jww*_*jww -1 automake autotools

另一个Autotools问题...我正在研究Fedora 27,并且正在尝试构建libidnlibidn2。我需要configure; make; make install实际工作。我需要它工作的机器只有Autoconf,Automake,Autopoint,Libtool和编译器工具。他们没有别的东西,就像这样<something>2html<something>2pdf所以我无法构建文档。我也不能autoreconf 按照手册运行因为那也坏了。

我不知道为什么这些工具会尝试构建文档,因为我使用禁用了它们--disable-gtk-doc --disable-gtk-doc-html --disable-gtk-doc-pdf。我曾尝试使用HELP2MAN=true和解决它MAKEINFO=true,但是Autotools找到了另一种破解方法:

gmake[2]: Entering directory '/home/Build-Scripts/libidn-1.33/doc'
echo '# This file is automatically generated.  DO NOT EDIT!          -*- makefile -*-' > Makefile.gdoc
echo >> Makefile.gdoc
echo 'gdoc_TEXINFOS =' >> Makefile.gdoc
echo 'gdoc_MANS =' >> Makefile.gdoc
echo >> Makefile.gdoc
for file in ../lib/idna.c ../lib/nfkc.c ../lib/pr29.c ../lib/punycode.c ../lib/stringprep.c ../lib/tld.c ../lib/toutf8.c ../lib/version.c ../lib/idn-free.c ../lib/strerror-idna.c ../lib/strerror-pr29.c ../lib/strerror-punycode.c ../lib/strerror-stringprep.c ../lib/strerror-tld.c; do \
  shortfile=`basename $file`; \
  echo "#" >> Makefile.gdoc; \
  echo "### $shortfile" >> Makefile.gdoc; \
  echo "#" >> Makefile.gdoc; \
  echo "gdoc_TEXINFOS += texi/$shortfile.texi" >> Makefile.gdoc; \
  echo "texi/$shortfile.texi: $file" >> Makefile.gdoc; \
  echo 'TABmkdir -p `dirname $@`' | sed "s/TAB/ /" >> Makefile.gdoc; \
  echo 'TAB$(PERL) ./gdoc -texinfo $(GDOC_TEXI_EXTRA_ARGS) $< > $@' | sed "s/TAB/       /" >> Makefile.gdoc; \
  echo >> Makefile.gdoc; \
  functions=`perl ./gdoc -listfunc $file`; \
  for function in $functions; do \
    echo "# $shortfile: $function" >> Makefile.gdoc; \
    echo "gdoc_TEXINFOS += texi/$function.texi" >> Makefile.gdoc; \
    echo "texi/$function.texi: $file" >> Makefile.gdoc; \
    echo 'TABmkdir -p `dirname $@`' | sed "s/TAB/       /" >> Makefile.gdoc; \
    echo 'TAB$(PERL) ./gdoc -texinfo $(GDOC_TEXI_EXTRA_ARGS) -function'" $function"' $< > $@' | sed "s/TAB/     /" >> Makefile.gdoc; \
    echo >> Makefile.gdoc; \
    echo "gdoc_MANS += man/$function.3" >> Makefile.gdoc; \
    echo "man/$function.3: $file" >> Makefile.gdoc; \
    echo 'TABmkdir -p `dirname $@`' | sed "s/TAB/       /" >> Makefile.gdoc; \
    echo 'TAB$(PERL) ./gdoc -man $(GDOC_MAN_EXTRA_ARGS) -function'" $function"' $< > $@' | sed "s/TAB/  /" >> Makefile.gdoc; \
    echo >> Makefile.gdoc; \
  done; \
  echo >> Makefile.gdoc; \
done
gmake Makefile
gmake[3]: Entering directory '/home/Build-Scripts/libidn-1.33/doc'
 cd .. && automake --gnu doc/Makefile
configure.ac:25: error: version mismatch.  This is Automake 1.15.1,
configure.ac:25: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:25: comes from Automake 1.14.1.  You should recreate
configure.ac:25: aclocal.m4 with aclocal and run automake again.
gmake[3]: *** [Makefile:1494: Makefile.in] Error 63
gmake[3]: Leaving directory '/home/Build-Scripts/libidn-1.33/doc'
gmake[2]: *** [Makefile:2205: Makefile.gdoc] Error 2
gmake[2]: Leaving directory '/home/Build-Scripts/libidn-1.33/doc'
gmake[1]: *** [Makefile:1333: all-recursive] Error 1
gmake[1]: Leaving directory '/home/Build-Scripts/libidn-1.33'
gmake: *** [Makefile:1235: all] Error 2
Run Code Online (Sandbox Code Playgroud)

我发现它令人难以置信很难相信Automake的1.14是必需的; 和Automake-1.15无法使用。我不在乎软件包版本检查,因此我想接下来跳过它们。

我该如何解决这个问题?

回到10,000英尺,Autotools是否具有任何具有用户界面经验的人来为他们的某些决策提供意见?或者,Autotools有什么大问题,以至于我觉得有必要中断我的构建,因为我的Automake版本比配置的软件包新?谁做出了这个明智的决定?


配置方法如下:

    PKG_CONFIG_PATH="/usr/local/lib64/pkgconfig" \
    CPPFLAGS="-I/usr/local/include -DNDEBUG" \
    CFLAGS= -m64 -march=native -fPIC" \
    CXXFLAGS= -m64 -march=native -fPIC" \
    LDFLAGS="-L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64 -Wl,--enable-new-dtags" \
    LIBS="-ldl -lpthread" \
./configure --prefix="/usr/local" --libdir="/usr/local/lib64" \
    --enable-shared
    # --disable-gtk-doc --disable-gtk-doc-html --disable-gtk-doc-pdf
Run Code Online (Sandbox Code Playgroud)

make就是所谓的:

MAKE_FLAGS=("-j" "$MAKE_JOBS")
MAKE_FLAGS+=("ACLOCAL=aclocal")
MAKE_FLAGS+=("AUTOCONF=autoconf")
MAKE_FLAGS+=("AUTOHEADER=autoheader")
MAKE_FLAGS+=("AUTOMAKE=automake")
MAKE_FLAGS+=("PERL=perl")
MAKE_FLAGS+=("HELP2MAN=true")
MAKE_FLAGS+=("MAKEINFO=true")

if ! "$MAKE" "${MAKE_FLAGS[@]}"
then
    echo "Failed to build IDN"
    [[ "$0" = "${BASH_SOURCE[0]}" ]] && exit 1 || return 1
fi
Run Code Online (Sandbox Code Playgroud)

Joh*_*ger 6

这条信息:

这是Automake 1.15.1,但定义…来自Automake 1.14.1

...表示Automake正在运行,这不是configure; make; make install。如前所述,您应该尽可能避免重建构建系统,而且通常确实是可能的。自动工具主要用于软件包维护者,不适用于软件包构建者。原则上,构建者只使用维护者通过Autotools创建的工件。

我正在使用Fedora 27,正在尝试构建libidn和libidn2。我需要配置;使; 使安装真正起作用。我需要它工作的机器只有Autoconf,Automake,Autopoint和Libtool。他们没有别的东西,所以我不能运行autoreconf,因为那也坏了。

例如,我刚刚获取了libidn(v 1.33)的Fedora 27源RPM,使用它在我的CentOS 7机器上解压缩了源发行版的副本,更改为生成的目录,并执行成功./configure; make(但未尝试make install) 。Autoconf和Automake已安装在我的计算机上,但没有运行,这与我的预期相同。

然而,如果自动工具实际上安装了构建机上,并且如果它们的输入(configure.acMakefile.am,等等)看起来比它们的输出(新的configureMakefile.in等),然后一个自动工具衍生的构建系统可能确实尝试重建这些输出(重建自身)。如果在构建机器上使用的Autotools版本与准备构建系统所使用的版本不同,则可能需要一些帮助。

如果这还行不通-通常是由于Autotools版本不匹配-通常的做法是运行autoreconf --install --force。对我来说,不清楚如何或为什么将您autoreconf弄坏以防止这种情况发生。在Fedora 27上,autoreconf它与打包在一起autoconf,因此,如果您拥有后者,那么您也应该拥有前者。尽管如此,autoreconf它只是其他几种工具的便利包装。您真的不需要它。例如,您应该能够通过以下命令更新构建系统中与Automake相关的部分

automake -f -c
Run Code Online (Sandbox Code Playgroud)

。您可能想通过运行Autoconf来跟进:

autoconf -f
Run Code Online (Sandbox Code Playgroud)

作为一种可能的替代方法,如果实际上尚未修改Autotools输入,则可能只是存在时间戳问题。在这种情况下,您可以尝试通过以下方式解决问题:

find . -name configure -o name config.status -o name Makefile.in \
  | xargs touch
Run Code Online (Sandbox Code Playgroud)

我发现它令人难以置信很难相信Automake的1.14是必需的; 和Automake-1.15.1不能使用。我不在乎软件包版本检查,因此我想接下来跳过它们。

这很好,因为没有 Automake的版本需要为包的任何支持的平台正常体形的一部分。“支持”哪些平台主要是构建系统的功能,而不是Autotools本身的功能,因此结果的确取决于构建该系统的人员的技能和远见。而且,您确实会关心所描述的特定程序包版本检查,因为忽略或禁止执行该程序包检查很有可能导致Automake和/或Autoconf输出无法正常工作。

Autotools在提供多平台支持方面的帮助比您想像的要多,但是它们不能自动地确保普遍支持。诸如CMake或Scons之类的替代品也不能。

回到10,000英尺,Autotools是否具有任何具有用户界面经验的人来为他们的某些决策提供意见?或者,Autotools有什么大问题,以至于我觉得有必要中断我的构建,因为我的Automake版本比配置的软件包新?谁做出了这个明智的决定?

再次抱歉,您遇到困难。但是自动工具无法破坏您的构建,因为它们不参与构建。由具有软件包维护者角色的人员使用自动工具来构建软件包的构建系统。如果生成的构建系统不能充分满足您要在其上构建软件包的机器和配置的需求,那么这不是Autotools的问题。

因为您似乎要将大量基于Autotools的软件包移植到其构建系统不支持的环境中,所以,您会接触到那些仅为支持的环境构建软件包的人所没有的Autotools。我倾向于认为您会以某种方式获得不必要的曝光,但这是一个单独的问题。无论如何,您都是在包维护模式下运行的,因此您需要从这种角度看待这种情况。您不仅在构建软件包。