httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 27550] New: - pcre symbol issues for apache modules
Date Tue, 09 Mar 2004 22:10:05 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27550>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27550

pcre symbol issues for apache modules

           Summary: pcre symbol issues for apache modules
           Product: Apache httpd-2.0
           Version: 2.0.48
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: dilinger@voxel.net


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.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message