[PATCH] Fix PCRE detection on OSX.

[Ruslan Ermilov]

On Mon, Dec 10, 2012 at 06:50:00PM +0400, Maxim Dounin wrote:
> Hello!
> 
> On Mon, Dec 10, 2012 at 02:31:42PM +0400, Ruslan Ermilov wrote:
> 
> [...]
> 
> > Fixing the first problem doesn't help to fix the second: the missing
> > /usr/include/pcre.h in OS X will still result in nginx (or any other
> > software using the default compiler and linker with default flags)
> > attempting to use /usr/local/include/pcre.h and /usr/lib/libpcre,
> > even if the compiler and linker are consistent and prefer
> > /usr/{include,lib}.
> 
> Consisten behaviour would be either to prefer /usr/local/{include,lib} 
> or to don't search them for anything by default.  This way both problems 
> observed on Mac OS X would be resolved.
> 
> > So I tent to repeat: avoid using /usr/local if at all possible.
> > (Or at least don't install libraries into /usr/local that also
> > exist in /usr/{include,lib}.)
> > 
> > A correct fix seems to be to exclude /usr/local/{include,lib} from
> > the default search paths (like FreeBSD does), but I'm not aware of
> > an easy way to do it.  And again, this is not unique to only OS X,
> > nor is nginx specific.
> 
> Just a side note: it looks like --with-local-prefix=/nonexistent 
> during gcc configure is a good way to do it.
> 
> Another side note: unfortunately, I was wrong claiming MacPorts 
> toolchain is good.  It has the same problem too, but with MacPorts 
> installed in /opt/local it uses /opt/local/include as headers 
> search path.
> 
> [...]
> 
> > A correct workaround should ensure that we don't try to use libpcre
> > from /usr/lib, because we know it's misinstalled, but shouldn't
> > otherwise pessimize other valid cases.  Since we don't know how
> > exactly the toolchain used is configured, we can merely delay the
> > default PCRE test on OS X:
> 
> I don't like the idea of delayed test either, for a reasons 
> similar to ones you don't like removing default search paths 
> testing: one should be able to supply appropriate search paths 
> which will be tested before we'll try to guess anything.
> 
> As a workaround for a particular build problem with PCRE on 
> Mac OS X something as simple as
> 
> --- a/auto/lib/pcre/conf	Mon Nov 26 18:01:49 2012 +0000
> +++ b/auto/lib/pcre/conf	Mon Dec 10 18:21:53 2012 +0400
> @@ -172,6 +172,7 @@ else
>              ngx_feature="PCRE JIT support"
>              ngx_feature_name="NGX_HAVE_PCRE_JIT"
>              ngx_feature_test="int jit = 0;
> +                              pcre_free_study(NULL);
>                                pcre_config(PCRE_CONFIG_JIT, &jit);
>                                if (jit != 1) return 1;"
>              . auto/feature
> 
> probably will be good enough.  It will prevent build failures 
> by checking if the code we are going to compile will compile.
> 
> (Yes, I understand that it won't resolve the root cause, i.e. the 
> library vs. headers mismatch.  And yes, I understand that it will 
> make PCRE JIT unavailable in some cases.  I don't think we care 
> though.)

I think we should commit this patch because it's correct.  :)

It will also fix the problem for those who can't fix it yourself,
with the small price by those who install stuff under /usr/local.