Re: checking for libraries that link but do not run

[Ben Pfaff]

Richard Ash <address@hidden> writes:

> 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.

This is a good point, and I think that Bob Friesenhahn might be
pointing out some related issues, but PSPP doesn't add any
libraries that it compiles itself to LIBS, only system libraries,
so this is not the problem that I am trying to solve in my
specific case.
-- 
Ben Pfaff 
http://benpfaff.org