Re: [PATCH] configure.ac: rework/fix the NEEDS_RESOLV and NEEDS_LIBGEN tests
- From
Brandon Casey <casey@nrlssc.navy.mil>
- Date
- Jul 22, 2009, 14:59 UTC
- Message-ID
- <Y0sTaUtyR0m1AxCoWzsTI2uclknZENRMzspLXWzGliyRILR9F2ffNg@cipher.nrlssc.navy.mil>
- In-Reply-To
- <7v3a8pdbdr.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 10 quoted lines
> Instead of saying that "hstrerror not in -lc means we do have -lresolv and > the function will be found there" blindly, we may want to have a nested > check. > > AC_CHECK_LIB([c], [hstrerror], [NEEDS_RESOLV=], > AC_CHECK_LIB([resolv], [hstrerror], [NEEDS_RESOLV=YesPlease])) > > But we do not have any provision for the case where -lc does not have it > and -lresolv does not have it either (or -lresolv does not exist) anyway, > so we might as well go with your patch.
Yeah, I understood how the NEEDS_SSL_WITH_CRYPTO test worked like this, but I didn't make the tests for NEEDS_RESOLV and NEEDS_LIBGEN any more complex for the same reason you state: we don't have any other provision...
> I take it that swapping [if-found][if-not-found] parameters is what the > autoconf documentation warns against? That is, both -lc and -lresolv may > have it but -lresolv one may be a specialized one you would not normally > want.
That's what I assume, and that's probably why AC_SEARCH_LIBS was invented which attempts to link without using any of the specified libraries first. It just doesn't seem to fit our needs in this case.
-brandon