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.

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