Re: Compiling against external PCRE

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAk9qFOwACgkQSMVSH78upWPn+wCeLwEwZvise60ZR2Qat5yoIJkB
XEgAni1FZMo1wEhQyAeCKcv9iQzzURTa
=YnLv
-----END PGP SIGNATURE-----