Hi all,
Resurrecting an old thread regarding using libtool for configure-time testing.
The motivation was to use libtool to work around -R-like options which break
compilation on certain platforms when not properly protected. In particular,
my response draws from these two messages...
http://lists.gnu.org/archive/html/autoconf/2010-06/msg00064.html
http://lists.gnu.org/archive/html/autoconf/2010-06/msg00066.html
On Tue, 29 Jun 2010, Ralf Wildenhues wrote:
>>> Well, first you need to use LT_OUTPUT before any such test, so the
>>> libtool script is created early in configure. Then, you need to write
>>> all link tests yourself, invoking ./libtool. Maybe somebody has written
>>> a macro to do that, somewhere (Autoconf Macro Archive?), I'm not aware
>>> of any existing ones, but I think a good one would be acceptable into
>>> libtool.m4.
On Tue, 29 June 2010, Peter Breitenlohner wrote:
>> Here the macro we are using in TeX Live for such tests (C and C++).
>> Our purpose is to test properties of libraries that can be either (1)
>> uninstalled libtool libraries already built when this configure runs,
>> or (2) installed libraries -- libtool or not.
>>
>> # _KPSE_USE_LIBTOOL()
>> # -------------------
>> AC_DEFUN([_KPSE_USE_LIBTOOL],
>> [## $0: Generate a libtool script for use in configure tests
>> AC_PROVIDE_IFELSE([LT_INIT], ,
>> [m4_fatal([$0: requires libtool])])[]dnl
>> LT_OUTPUT
>> m4_append([AC_LANG(C)],
>> [ac_link="./libtool --mode=link --tag=CC $ac_link"
>> ])[]dnl
>> AC_PROVIDE_IFELSE([AC_PROG_CXX],
>> [m4_append([AC_LANG(C++)],
>> [ac_link="./libtool --mode=link --tag=CXX $ac_link"
>> ])])[]dnl
>> AC_LANG(_AC_LANG)[]dnl
>> ]) # _KPSE_USE_LIBTOOL
On Tue, 29 Jun 2010, Ralf Wildenhues wrote:
> A general set of macros could be LT_USE_LIBTOOL_PUSH and _POP and
> could adjust the AC_LANG setting of all configured libtool tags;
> the pop macro could reset them to their original state afterwards;
> that would help for encapsulation. Or some better names I can't
> think of right now.
I have used the _KPSE_USE_LIBTOOL() approach with success. Thank you both.
I have been unable to think of the right way to encapsulate the details into a
push/pop macro pair as Ralf suggested. It seems simple to use AC_LANG_DEFINE
(from lang.m4) to create, say, a "language" named LIBTOOLC which uses COPY-FROM
to mimic the C language definition and then augments ac_compile and ac_link as
suggested above. Then AC_LANG_PUSH([LIBTOOLC]) and AC_LANG_POP([LIBTOOLC])
should then, I think, do the right thing.
However, that approach seems brittle in that anyone calling AC_LANG_PUSH([C])
after AC_LANG_PUSH([LIBTOOLC]) will clobber the libtool-specific definitions.
Such pushes happen all the time in people's macros to defensively ensure the
correct language is selected before performing some tests. Using something
other than a language name, I think, will encounter the same trouble. Is that
trouble fundamental to the way the AC_LANG_{PUSH,POP} system is defined, or is
there a way around it?
For macro sets entirely controls, a different approach which replaces all the
AC_LANG_{PUSH,POP} pairs with a libtool-friendly macro like the following
(written for the boost.m4 macros up on Github) seems to work well:
# _BOOST_LANG_PUSH_CXX
# --------------------------------------------------------
# Same as AC_LANG_PUSH for C++ but modifies ac_compile and ac_link to always
# employ ./libtool from LT_OUTPUT. This reduces our exposure to compiler and
# linker differences. Attempts to ensure others playing similar libtool tricks
# with ac_compile and ac_link do not break us.
AC_DEFUN([_BOOST_LANG_PUSH_CXX],[
AC_REQUIRE([LT_OUTPUT])dnl
AC_LANG_PUSH([C++])dnl
case "$ac_compile" in #(
./libtool*) : ;;#(
*) ac_compile="./libtool --mode=compile --tag=CXX $ac_compile" ;;
esac
case "$ac_link" in #(
./libtool*) : ;;#(
*) ac_link="./libtool --mode=link --tag=CXX $ac_link" ;;
esac
]) # _BOOST_LANG_PUSH_CXX
# _BOOST_LANG_POP_CXX
# --------------------------------------------------------
# Same as AC_LANG_POP for C++.
# For symmetry with _BOOST_LANG_PUSH_CXX
AC_DEFUN([_BOOST_LANG_POP_CXX],[
AC_LANG_POP([C++])dnl
]) # _BOOST_LANG_POP_CXX
The push macro does a bit of defensive checking to work correctly even
if someone uses a _KPSE_USE_LIBTOOL()-like technique and directly
modifies the ac_compile/ac_link in their configure.ac a la
LT_OUTPUT
m4_append([AC_LANG(C++)],[
ac_compile="./libtool --mode=compile --tag=CXX $ac_compile"
ac_link="./libtool --mode=link --tag=CXX $ac_link"
])[]dnl
Has the pushing/popping of libtool-based compilation and linking been solved
in some other way besides this particular approach?
Thanks,
Rhys
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
