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])
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 is not mentioned the Makefile.am, but I have made sure that it is honored in the libtool command by running make -n.
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)
Edit: 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.
Libtool has a -no-undefined option.
GNU ld has a --no-undefined option.
You should let libtool know about it from inside the Makefile.am, and let it take care of forwarding to the linker:
configure.ac
AC_CANONICAL_HOST
if test "$host_os" = cygwin
then
EXTRA_LDFLAGS="-no-undefined"
fi
AC_SUBST([EXTRA_LDFLAGS])
Makefile.am
AM_LDFLAGS = $(EXTRA_LDFLAGS) ...
As a general rule, you should not mess around with CPPFLAGS, LDFLAGS, etc from configure.ac, since the user might need to change them while invoking "make".
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])
This way, the macro that tests for a C++ compiler succeeds because LDFLAGS is pristine; but the actual codebase uses the extra flag.
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.
