[PATCH] Fix PCRE detection on OSX.

[Maxim Dounin]

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.)

-- 
Maxim Dounin
http://nginx.com/support.html