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

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