autoconf/automake/libtool - 如何取消定义 PACKAGE_NAME、PACKAGE_TARNAME、PACKAGE_VERSION 等

Posted 2023-02-22

【中文标题】autoconf/automake/libtool - 如何取消定义 PACKAGE_NAME、PACKAGE_TARNAME、PACKAGE_VERSION 等

【英文标题】：autoconf/automake/libtool - how to undefine PACKAGE_NAME, PACKAGE_TARNAME, PACKAGE_VERSION and so on

【发布时间】：2018-09-05 19:16:27

【问题描述】：

构建日志：

20:10:36 make[3]: Entering directory `/home/ubuntu/build/ColossusCoinXT/distsrc-i686-pc-linux-gnu/src/minizip'
20:10:36 /bin/bash ./libtool  --tag=CC   --mode=compile gcc -m32 -DPACKAGE_NAME=\"minizip\" -DPACKAGE_TARNAME=\"minizip\" -DPACKAGE_VERSION=\"1.2.8\" -DPACKAGE_STRING=\"minizip\ 1.2.8\" -DPACKAGE_BUGREPORT=\"bugzilla.redhat.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"minizip\" -DVERSION=\"1.2.8\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.  -I./../.. -I/home/ubuntu/build/ColossusCoinXT/depends/i686-pc-linux-gnu/share/../include/   -pipe -O2 -O2 -g -c -o ioapi.lo ioapi.c  
20:10:36 libtool: compile:  gcc -m32 -DPACKAGE_NAME=\"minizip\" -DPACKAGE_TARNAME=\"minizip\" -DPACKAGE_VERSION=\"1.2.8\" "-DPACKAGE_STRING=\"minizip 1.2.8\"" -DPACKAGE_BUGREPORT=\"bugzilla.redhat.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"minizip\" -DVERSION=\"1.2.8\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I./../.. -I/home/ubuntu/build/ColossusCoinXT/depends/i686-pc-linux-gnu/share/../include/ -pipe -O2 -O2 -g -c ioapi.c  -fPIC -DPIC -o ioapi.o
20:10:36 gcc: error: 1.2.8": No such file or directory

问题在第 3 行："-DPACKAGE_STRING=\"minizip 1.2.8\""，由于空格，编译器将此定义解释为两个不同的参数。我正在寻找解决方法，最简单的方法似乎是取消定义这些 AC_INIT 预处理器符号，但我没有找到这样做的方法。

配置.ac：

AC_INIT([minizip], [1.2.8], [bugzilla.redhat.com])
AC_CONFIG_SRCDIR([minizip.c])
AM_INIT_AUTOMAKE([no-define foreign])
LT_INIT
...

寻找快速解决方法，谢谢！

【问题讨论】：

一些较旧的项目，特别是 binutils 和 GCC，使用旧形式的 AC_INIT，只需要源目录中的文件名。手册解释说它等同于AC_INIT（无参数），后跟AC_CONFIG_SRCDIR([filename])。据我所知，这实际上仍然有效。您可能需要定义宏 AC_PACKAGE_NAME、AC_PACKAGE_VERSION 和其他一些宏，并为 Automake/Libtool 使用 AC_SUBST([PACKAGE_NAME], [AC_PACKAGE_NAME]) 等。有关更多信息，您需要查看 /usr/share/autoconf/autoconf/general.m4 中的私有宏 _AC_INIT_PACKAGE。

这比您的解决方案更有效，而且它可能会在某些时候中断，这就是我没有将其作为答案发布的原因。

【参考方案1】：

现在我使用下一个解决方法：

AC_CONFIG_COMMANDS([quickfix], [sed -i 's/minizip\\\ 1.2.8/minizip-1.2.8/g' Makefile])
AC_OUTPUT

如果您知道，请发布更好的解决方案。

【参考方案2】：

看看你的构建输出：

正如 make 打印的那样，make 调用的 libtool 命令行包含 -DPACKAGE_STRING=\"minizip\ 1.2.8\"，这是在 shell 上传递包含空格字符的参数的好方法。

当 libtool 打印它时，libtool 调用的 gcc 编译命令包含 "-DPACKAGE_STRING=\"minizip 1.2.8\""，这是在命令行上传递包含空格字符的参数的另一种好方法。

目前还没有发现任何错误。

但是，gcc 打印的错误消息表明，最终调用的 gcc 命令实际上与 libtool 打印的命令不同。

这留下了两种可能性：

您的构建使用的libtool 脚本已损坏，并以与打印方式不同的方式调用gcc。您可以尝试运行 make distclean 并重新运行 autoreconf 和 configure 从头开始​​重建 minizip 构建系统，其中包括 libtool 脚本。

libtool 脚本正确调用了gcc 命令，但gcc 命令是实际 gcc 的包装器，并且该包装器不正确地将其参数传递给实际的 gcc，这反过来又扼杀了不正确的论据。包装gcc 的软件包的一个示例是ccache，但还有其他示例。

检查这一点的一种方法是在 shell 中运行 which gcc，然后分析结果：它属于哪个包，是否使用替代方案重定向，等等。可能有这个软件的更新版本，带有引用错误已修复。

minizip 源代码树本身很好（在 Debian 10 上测试）：

[user@host ~]$ git clone https://github.com/madler/zlib.git
[…]
[user@host ~]$ cd zlib/contrib/minizip
[user@host minizip]$ git checkout -b minizip-1.2.8 v1.2.8
[…]
[user@host minizip]$ autoreconf -vis .
[…]
[user@host minizip]$ ./configure --prefix=$PWD/_i
[…]
[user@host minizip]$ make
/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"minizip\" -DPACKAGE_TARNAME=\"minizip\" -DPACKAGE_VERSION=\"1.2.8\" -DPACKAGE_STRING=\"minizip\ 1.2.8\" -DPACKAGE_BUGREPORT=\"bugzilla.redhat.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"minizip\" -DVERSION=\"1.2.8\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I.  -I./../..   -g -O2 -MT ioapi.lo -MD -MP -MF .deps/ioapi.Tpo -c -o ioapi.lo ioapi.c
libtool: compile:  gcc -DPACKAGE_NAME=\"minizip\" -DPACKAGE_TARNAME=\"minizip\" -DPACKAGE_VERSION=\"1.2.8\" "-DPACKAGE_STRING=\"minizip 1.2.8\"" -DPACKAGE_BUGREPORT=\"bugzilla.redhat.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"minizip\" -DVERSION=\"1.2.8\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I./../.. -g -O2 -MT ioapi.lo -MD -MP -MF .deps/ioapi.Tpo -c ioapi.c  -fPIC -DPIC -o .libs/ioapi.o
libtool: compile:  gcc -DPACKAGE_NAME=\"minizip\" -DPACKAGE_TARNAME=\"minizip\" -DPACKAGE_VERSION=\"1.2.8\" "-DPACKAGE_STRING=\"minizip 1.2.8\"" -DPACKAGE_BUGREPORT=\"bugzilla.redhat.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"minizip\" -DVERSION=\"1.2.8\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I./../.. -g -O2 -MT ioapi.lo -MD -MP -MF .deps/ioapi.Tpo -c ioapi.c -o ioapi.o >/dev/null 2>&1
mv -f .deps/ioapi.Tpo .deps/ioapi.Plo
[…]
libtool: link: gcc -shared  -fPIC -DPIC  .libs/ioapi.o .libs/mztools.o .libs/unzip.o .libs/zip.o   -L./../.. -lz  -g -O2   -Wl,-soname -Wl,libminizip.so.1 -o .libs/libminizip.so.1.0.0
libtool: link: (cd ".libs" && rm -f "libminizip.so.1" && ln -s "libminizip.so.1.0.0" "libminizip.so.1")
libtool: link: (cd ".libs" && rm -f "libminizip.so" && ln -s "libminizip.so.1.0.0" "libminizip.so")
libtool: link: ar cru .libs/libminizip.a  ioapi.o mztools.o unzip.o zip.o
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libminizip.a
libtool: link: ( cd ".libs" && rm -f "libminizip.la" && ln -s "../libminizip.la" "libminizip.la" )
[user@host minizip]$ _