在带有libtool的自动工具中使用LDFLAGS

问题描述

根据操作系统，我在configure.ac中定义一个特殊的LDFLAGS:

Depending on the OS, I define a special LDFLAGS in my configure.ac:

AC_CANONICAL_HOST
if test "$host_os" = cygwin
then
    LDFLAGS="$LDFLAGS -Wl,-no-undefined"
    export LDFLAGS
fi
AC_SUBST([LDFLAGS])

该软件包使用AC_PROG_LIBTOOL，并且当LDFLAGS传递给libtool时，仍保留-Wl前缀，并且链接程序不理解该选项.如果删除此前缀，则AC_PROG_CXX宏将失败，因为GCC本身会阻塞-no-undefined.我在做什么错了?

The package uses AC_PROG_LIBTOOL and when LDFLAGS is passed to libtool, the -Wl prefix remains, and the linker doesn't understand the option. If I remove this prefix, the AC_PROG_CXX macro fails, because GCC chokes on -no-undefined by itself. What am I doing wrong?

LDFLAGS没有提到Makefile.am，但是我通过运行make -n确保在libtool命令中尊重它.

LDFLAGS is not mentioned the Makefile.am, but I have made sure that it is honored in the libtool command by running make -n.

我正在Cygwin 1.7.28(0.271/5/3)下使用autoconf 2.69，automake 1.14，gmake 4.0和gcc 4.8.2

I'm using autoconf 2.69, automake 1.14, gmake 4.0 and gcc 4.8.2 under Cygwin 1.7.28(0.271/5/3)

我有几十个Makefile.am，其中一半以上来自外部库-我更希望从中央位置控制这些标志.

I have a few dozen Makefile.ams, more than half of which are from external libraries -- I'd much prefer to control these flags from a central location.

推荐答案

为了不修改数十个Makefile，我最终使用了LDFLAGS.诀窍是将其设置在宏之后:

In ordered not to modify dozens of Makefiles, I have ended up using LDFLAGS. The trick was to set it after the AC_PROG_CXX macro:

AC_PROG_CXX
if test "$host_os" = cygwin
then
    LDFLAGS="-no-undefined $LDFLAGS"
fi
AC_SUBST([LDFLAGS])

这样，因为LDFLAGS是原始的，所以测试C ++编译器的宏成功了.但是实际的代码库使用了额外的标志.

This way, the macro that tests for a C++ compiler succeeds because LDFLAGS is pristine; but the actual codebase uses the extra flag.

通过在末尾放置$LDFLAGS替换，来自环境的任何用户选项在配置时优先.并且仍然可以在make LDFLAGS=...时进行覆盖.

By putting the $LDFLAGS substitution at the end, any user options from the environment take precedence at configure time; and overriding at make time with make LDFLAGS=... is still possible.

这篇关于在带有libtool的自动工具中使用LDFLAGS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！