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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel