Re: autoconf/176: AC_CHECK_LIB fails to add OTHER-LIBRARIES to LIBS

[Rainer Orth]

Erez Zadok writes:

> In message <address@hidden>, Akim Demaille writes:
> > 
> [...]
> > Sorry, I was confused.  It's no duplicate, but the comments I gave
> > about AC_CHECK_LIB apply here too: I can understand you don't like the
> > behavior, but it is what is documented.
> 
> Akim, I understand that, but just b/c it is documented, does it mean that it
> works right?  If applying this patch will constitute an underivable change
> in documented behavior, then I would suggest a new macro.  If you think the
> existing behavior is proper (I don't), or might disrupt too many people,
> then it would be best to keep it as is and offer a new macro.
> 
> IMO, AC_CHECK_LIB doesn't work "right" in the way that most people naturally
> would expect of it.  That is why I wrote the second version that I've used
> in my am-utils package for over 3 years now, and running on 70+ platforms
> with success.  I'm very happy with it and use it instead of the std
> AC_CHECK_LIB everywhere.  I would love to see this new functionality offered
> in autoconf.  I think it would provide really useful functionality that many
> could use.

fully agreed (of course :-)  Akim, if AC_CHECK_LIB behaves `right' as it
does now, what's the use of the OTHER-LIBRARIES argument?  The macro
doesn't export the information if it had to use them to get the test
program for FUNCTION to link or not, so what can I do as a user?  Always
link with OTHER-LIBRARIES because it might be necessary no some platforms?
But what about OTHER-LIBRARIES (like libnsl on IRIX used to be) which cause
harm (i.e. correct programs to fail in unexpected ways) when they are used
but not needed?

        Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: address@hidden