Nmap Development mailing list archives

Re: [BUG] after pcre.h is found, configure checks for pcre/pcre.h


From: David Fifield <david () bamsoftware com>
Date: Tue, 11 Sep 2012 13:26:04 -0700

On Tue, Sep 11, 2012 at 10:26:15PM +0200, John Spencer wrote:
On 09/10/2012 09:15 PM, David Fifield wrote:


This is a bit annoying to fix, so I think we will only do so if we get a
patch.

The problem is not this part of configure.ac, which checks for pcre.h,
and then only checks for pcre/pcre.h if that fails:

# If they didn't specify it, we try to find it
if test $have_pcre != yes -a $requested_included_pcre != yes ; then
  AC_CHECK_HEADER(pcre.h,
    AC_CHECK_LIB(pcre, pcre_version, [have_pcre=yes ]),
    [AC_CHECK_HEADER(pcre/pcre.h,
      [AC_CHECK_LIB(pcre, pcre_version, [have_pcre=yes])]
    )]
  )
fi

The extra check is this one, which is done if either pcre.h or
pcre/pcre.h is found:

# We only need to check for and use this if we are NOT using included pcre
  AC_CHECK_HEADERS(pcre/pcre.h)

Notice that the first checks are done with AC_CHECK_HEADER and the
second check is done with AC_CHECK_HEADERS. AC_CHECK_HEADERS has the
effect of defining HAVE_PCRE_PCRE_H, which is used in a couple of places
like nse_pcrelib.h.

why not use AC_CHECK_HEADERS for the first test then ?

AC_CHECK_HEADERS is not used for the first test because we don't just
want to define HAVE_PCRE_H: we want to follow it with a check for
libpcre, and then check for pcre/pcre.h if it's not present.

I don't think it's a very hard thing to fix, but seeing as it isn't
really causing any problems, I'm not going to spend time fixing it and
testing the change. If you or someone else wants to contribute a patch
though, it will be very welcome.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: