Re: checking for header/library mismatch, rpath problem?

[Rhys Ulerich]

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