Compiling against external PCRE
Ian Silvester <[email protected]>
| Newsgroups | gmane.comp.web.privoxy.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi all, 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: 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. 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? 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. Cheers, Ian ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure