autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] Document traps of AC_CHECK_LIB for standard functions


From: Noah Misch
Subject: [PATCH] Document traps of AC_CHECK_LIB for standard functions
Date: Mon, 6 Dec 2004 19:37:59 -0800
User-agent: Mutt/1.5.6i

Hi Stepan, Mark,

On Tue, Dec 07, 2004 at 01:59:32AM +0100, Stepan Kasal wrote:
> On Mon, Dec 06, 2004 at 04:31:24PM -0800, Mark D. Baushke wrote:
> > I suspect there may need to be a separate test to see if the entry
> > points are in the default libraries before looking to add new libraries
> > to the LIBS list. That would seem to be the general fix for supporting a
> > system such as UNICOS that does not seem to do what you want it to do.
> > However, it is not clear to me as to what changes are needed in autoconf
> > to deal with this situation in a complete manner.

I think AC_SEARCH_LIBS does this.

> Perhaps the right solution would be to grep for the message in the
> compilers output and taking it as a failure if the message is found.

I just remembered that using AC_CHECK_LIB for standard functions also harms
IRIX.  Developers should use AC_SEARCH_LIBS unless they wish to prefer function
definitions in auxiliary libraries over those in the standard libraries.  The
appended patch documents that recommendation.

It may still be a good idea to handle the UNICOS problem by examining stderr
from cc, especially because developers may sometimes wish to prefer function
definitions in auxiliary libraries and therefore need to use AC_CHECK_LIB.  For
example, I recall that Solaris defines stub thread functions in libc, but to
actually create a threaded program, you must link with the real versions in a
threads library.  That is a sure corner case, though.  What do you think?

2004-12-06  Noah Misch  <address@hidden>

        * doc/autoconf.texi (Libraries): Recommend AC_SEARCH_LIBS for functions
        sometimes present in standard libraries.  IRIX problem description from:
        http://freeware.sgi.com/howto.html#a0

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.837
diff -u -r1.837 autoconf.texi
--- doc/autoconf.texi   11 Oct 2004 21:42:06 -0000      1.837
+++ doc/autoconf.texi   7 Dec 2004 03:25:05 -0000
@@ -3600,6 +3600,20 @@
 always fail with unresolved symbols.  The @var{other-libraries} argument
 should be limited to cases where it is desirable to test for one library
 in the presence of another that is not already in @code{LIBS}.
+
+Standard functions such as @code{gethostbyname}, @code{socket}, and
address@hidden appear in standard address@hidden is, libraries to
+which the compiler driver normally links every programs.} on some
+systems and in auxiliary libraries (resp. @file{libnsl},
address@hidden, @file{libm}) elsewhere.  If you prefer definitions
+from a standard library where available, use @code{AC_SEARCH_LIBS}
+instead of @code{AC_CHECK_LIB}.  On @sc{unicos}, linking with a
+nonexistent library does not produce an error, so testing for a function
+definition actually present in a standard library in some other library
+always succeeds.  On @sc{irix}, common auxiliary libraries exist but
+define legacy versions of standard functions.  Rewriting a test like
address@hidden(nsl, gethostbyname)} as
address@hidden(gethostbyname, nsl)} avoids these problems.
 @end defmac
 
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]