[PATCH] Fix PCRE detection on OSX.

[Maxim Dounin]

Hello!

On Fri, Dec 07, 2012 at 11:01:18PM -0800, Piotr Sikora wrote:

> Hey Ruslan,
> 
> > And what happens if Apple fixes it the other day by putting PCRE
> > headers (back?) under /usr/include?  How do we compile with the
> > version in /usr/include and /usr/lib then?
> 
> - if [ "$NGX_SYSTEM" = "Darwin" ]; then
> + if [ "$NGX_SYSTEM" = "Darwin" -a "$NGX_RELEASE" < "X.Y.Z" ]; then
> 
> where X.Y.Z is the fixed release... But this is really a question for
> another day, because OSX ships with libpcre without pcre.h at least
> from the OSX 10.6 release (so from 2009).

The problem with Mac OS X is not with libpcre withou pcre.h, but with 
broken toolchain which prefers headers from /usr/local/include but 
libraries from /usr/lib by default.

Here is a test:

#!/bin/sh -e

# in /usr/ {include, lib}:
# bad foo.h, good libfoo.a

# in /usr/local/ {include, lib}
# good foo.h, bad libfoo.a

CC=cc
AR=ar

echo '#error "broken foo.h in /usr/include"' > foo.h
install foo.h /usr/include/

echo 'char *foo() { return "broken libfoo.a from /usr/lib"; }' > foo.c
${CC} -c -o foo.o foo.c
${AR} -rs libfoo.a foo.o
install libfoo.a /usr/lib/

echo '#warning "good foo.h in /usr/local/include"' > foo.h
echo 'char *foo();' >> foo.h
install foo.h /usr/local/include/

echo 'char *foo() { return "good libfoo.a from /usr/local/"; }' > foo.c
${CC} -c -o foo.o foo.c
${AR} -rs libfoo.a foo.o
install libfoo.a /usr/local/lib/

cat << END > test.c

#include <foo.h>
#include <stdio.h>

int
main(void) {
    printf("%s\n", foo());
}

END

${CC} -o test -l foo test.c
./test

On Mac OS X 10.7.5 with Xcode 4.5.2 it results in:

# ./test.sh
In file included from test.c:2:
/usr/local/include/foo.h:1:2: warning: "good foo.h in /usr/local/include" [-W#warnings]
#warning "good foo.h in /usr/local/include"
 ^
1 warning generated.
broken libfoo.a from /usr/lib

That is, header file from /usr/local/include was used, but library 
from /usr/lib.  This is the clear incosistency in build toolchain 
which will result in various build problems till fixed.

Easy fix is to avoid using /usr/local/ till the problem is fixed.  
Alternatively, one may try to provide appropriate compiler 
arguments to fix the toolchain.  Another alternative would be to 
switch to a different toolchain (e.g. MacPort's provided one).

I don't think nginx should try to do anything with it as it's 
indeed not our problem.  But if we are going to, it probably 
should be something better that just not searching for PCRE in 
default compiler search paths, as it e.g. breaks compilation with 
search paths explicitly configured by a user via ./configure 
arguments.

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