Currently, apache2 includes a full version of pcre-3.9 in its sources;
this is built during compilation, and statically linked against.  The
symbols from this library, are exported to apache modules.  This is
undesirable for some apache modules; for example, php.  Php links
against libpcre on the system; however, it will happily pick up the pcre
symbols in the apache binary before the symbols in the pcre shared
library.  This breaks php functions such as pcre_match(), which expect a
relatively new version of pcre to be used (3.9 doesn't cut it; it always
fails w/ that).

There are a number of solutions, here.  I attempted upgrading the pcre
included in apache; however, I had no way to know if the various win32
hacks introduced to the pcre build system would still work.  I opted to
not bother, since I have no way to test such work except for on a unix
system.

An alternate solution is to check for pcre on the build system, and link
against that instead of building pcre for apache.  This works, but
introduces other issues.  With apache2 looking for the posix regex
functions in shared libraries, it ends up using the glibc
implementations for reg{comp,exec,free,error} instead of the pcre
implementations of these function.  On my system, the glibc
implementations segfault somewhere inside glibc; it's much safer to
stick w/ the pcre versions.  So, aside from the autoconf-ery that's
necessary to do the pcre system checks, there are some additional code
changes necessary to make sure that the pcre functions are called
instead of the glibc functions.  This is mainly some ugly code
duplication.  The patch that implements this change is here:
<http://sloth.voxel.net/~dilinger/020-external_pcre.patch>

A third solution is to simply change the internal pcre library to have
its own namespace.  This ensures that apache uses a pcre that it's been
fully tested with, while apache modules don't use them in place of a
system-supplied pcre.  What I've done in the following patch is to
prefix the posix regex functions in pcre with ap_pcreposix, and to
prefix the other pcre regex functions with ap_pcre.  The interface that
apache is _suppose to_ export to modules has not changed.  That patch is
here:
<http://sloth.voxel.net/~dilinger/021-pcre_mangle_symbols.patch>

I prefer the 021-pcre_mangle_symbols.patch patch, even though it's
larger; it ensures stability, at the cost of some code duplication.  The
020-external_pcre.patch patch isn't as clean as I'd hoped, and for the
added complexity, not much memory is saved.

Anyways, links to both patches are supplied so that you folks can decide
between the preferred method.  Please consider applying either one of my
patches, or an equivalent patch, so that pcre issues in external apache
modules are solved.



Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to