Nicolas Sebrecht <nicolas.s.dev@xxxxxx> writes: > I wonder if we could have some feedbacks on this patch. The change on > the whole file may make more bad than good. Works as expected here on > Linux (glibc 2.9). > > Otherwise, the following lines are sufficient to correct the original > error: > >> test -n "$NEEDS_RESOLV" && LIBS="$LIBS -lresolv" >> >> -AC_CHECK_LIB([gen], [basename], >> +AC_SEARCH_LIBS([basename], [gen], >> [NEEDS_LIBGEN=], >> [NEEDS_LIBGEN=YesPlease]) >> AC_SUBST(NEEDS_LIBGEN) Thanks. The autoconf documentation does not give much confidence either way: AC_CHECK_LIB requires some care in usage, and should be avoided in some common cases. It is unclear what these "some" are, and is sufficiently unclear for us to decide if our situation falls into these "some common cases." The only problem it cites is that alternative libraries may contain a variant implementation of the same function found in a more common library, in which case you may not want to use such an alternative implementation, and I do not think "basename() in -lgen" falls into that category. It does say These days it is normally better to use AC_SEARCH_LIBS(...) instead of AC_CHECK_LIB(...). but without any further justification, which does not help building confidence in the suggestion. It is very tempting to revert the configure.ac part of commit ecc395c especially in an -rc freeze, but if some autoconf experts can help us decide by clarifying the situation, and explain why AC_SEARCH_LIBS() is indeed the better way these days (which I suspect it is), I'd say we can apply your patch to favor AC_SEARCH_LIBS() over AC_CHECK_LIB() with more confidence. If autoconf people say AC_SEARCH_LIBS() should be preferred over AC_CHECK_LIB(), it probably is the right thing to do. But I want to have a warmer-and-fuzzier feeling that we understand why it went wrong, rather than blindly doing what the documentation says because the documentation tells us to. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html