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 ------- Additional Comments From [EMAIL PROTECTED] 2004-11-10 09:17 ------- The following notes were sent to me by Paul Argentoff to accompany the preceeding patch. - - - - - - This is patch by Andres Salomon <[EMAIL PROTECTED]>, with typo fixed by Paul Argentoff <[EMAIL PROTECTED]> This patch fixes problems seen by apache modules attempting to run regex stuff, and getting apache's internal pcre implementation. It contains two parts; the first (the autoconf stuff) checks if libpcre is installed on the host system. If it is, that pcre is used to build apache2. If it's not, apache2 compiles its own pcre, and statically links against it. The second part of this patch forces pcre to be used. Apache, by default, calls the posix regex functions (reg{exec,comp,free,error}) internally. If glibc was sane, this would be fine. Unfortunately, it's not. So, when apache calls these regex functions, it's anyones guess as to whether it will use glibc's regex functions, or the pcre regex functions. The glibc regex functions segfault (within glibc) on my system. So, to ensure sanity, we force use of pcre regex functions. I need to do a bit more testing w/ apache's internal pcre, but for debian's purposes (pcre in /usr), it works fine. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
