Re: checking for libraries that link but do not run

[Richard Ash]

On Mon, 2009-10-05 at 12:13 -0500, Bob Friesenhahn wrote:
> On Mon, 5 Oct 2009, Ben Pfaff wrote:
> >
> > To try to head off the problem, I'm thinking about putting
> > something like this after each command that adds to LIBS:
> >    AC_RUN_IFELSE([AC_LANG_PROGRAM([], [])],
> >                  [:],
> >                  [AC_MSG_FAILURE([Cannot run program linked against 
> > $LIBS.])],
> >                  [:])
> >
> > Am I on the right track?  It seems to me that there should
> > already be a mechanism to help with this, but I do not see one.
> 
> This is a rather complex issue since the problem can be corrected by 
> LD_LIBRARY_LFLAGS, ldconfig/crle, by formally installing the library, 
> or by libtool at link time.  Since autoconf does not use libtool in 
> its testing, it does not benefit from the extra smarts provided by 
> libtool, and so autoconf tests are more fragile.  For example, 
> autoconf can't know about library dependencies that libtool may be 
> able to figure out later (via installed .la files) and so the 
> configure script developer needs to provide way to add all of these 
> dependencies to LIBS.
Not to mention that a more sophisticated configure script might work out
that the local source tree contains sources to some library you use, but
they haven't been compiled yet. If you start trying to link against
those libraries, you will get a link error, although by the time you
link your final program, make has built the relevant libraries and you
can link them.

My solution for this problem in Audacity's configure was to keep two
LDFLAGS variables, one set that are the default for configure, and into
which compiler feature flags etc go, and another set which will be used
in the build, but aren't valid yet. The latter are added to the former
either right at the end of configure, or actually in the Makefiles, I
can't remember which.

Richard