Re: Compiling against external PCRE

Thanks for jogging my memory about the prior discussion Fabian!

Xcode bundles gcc 4.2.1 which (as you wrote previously) doesn't automatically search the sensible locations for header files. Indeed, the pcre make install puts the header files at /usr/local/include. Also in that prior discussion you quoted the following as your settings for LDFLAGS & CPPFLAGS:

LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include/ CC=... ./configure ...

One ignorant questions - why CPPFLAGS and not CFLAGS?

Ian


On 2012-03-21, at 1:50 PM, Fabian Keil wrote:

> Ian Silvester <[email protected]> wrote:
> 
>> My next task is to create an OS X distribution with a more recent, external PCRE library bundled with it (on the basis that the vast majority of OS X Privoxy users won't have this library installed for themselves and hence there'll be no installation conflicts).
>> 
>> I've done the usual toolchain dance and now have the pcre binaries installed at /usr/local/lib, and have worked out from Privoxy's configure.in that I need the two header files pcre.h and pcreposix.h present in Privoxy's source directory. Nevertheless, autoconf still tells me the following:
> 
> Those headers don't need to be in Privoxy's source
> directory as long as the compiler finds them.
> 
>> checking for pcre_compile in -lpcre... no
>> checking for regcomp in -lpcreposix... yes
>> checking pcreposix.h usability... no
>> checking pcreposix.h presence... yes
>> configure: WARNING: pcreposix.h: present but cannot be compiled
>> configure: WARNING: pcreposix.h:     check for missing prerequisite headers?
>> configure: WARNING: pcreposix.h: see the Autoconf documentation
>> configure: WARNING: pcreposix.h:     section "Present But Cannot Be Compiled"
>> configure: WARNING: pcreposix.h: proceeding with the preprocessor's result
>> configure: WARNING: pcreposix.h: in the future, the compiler will take precedence
>> checking for pcreposix.h... yes
>> 
>> It seems I have two problems:
>> 
>> 1. For reasons I cannot fathom, the first library check (pcre, pcre_compile,) fails to find the function pcre_compile in the library pcre. This function is present in both the bundled and manually-installed versions of pcre so I'm at a loss as to why this check fails.
> 
> Maybe the compiler doesn't look for pcre in the right places.
> Copying the headers into Privoxy's source directory is not
> necessarily sufficient for a compile and link test.
> 
>> 2. Whilst the second library check does succeed, the subsequent header check doesn't go so well. Whilst the header file is found, it seems (from the reading I've been doing about the "Present But Cannot Be Compiled" warning) that there is another header on which pcreposix.h depends, but I've no idea which this is.
>> 
>> Can anyone who has this working shed any light on either problem?
> 
> Unlike pcre_compile(), regcomp() is also POSIX standardized and
> may be available in the system libc. It's not a big deal, but I
> wouldn't rule out the possibility that autoconf is finding
> the wrong one.
> 
> Getting the pcre_compile() check working might fix this as a side effect.
> 
>> Separately, apart from the concerns regarding bundling a library that the end user might already have (another version of) installed, are there any other reasons not to go this route? It seems to me that bundling a newer pcre is nothing but a good idea.
> 
> I have nothing to add since the last time we discussed the pros
> and cons of bundling pcre.
> 
> Fabian
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
> Ijbswa-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ijbswa-developers


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure