httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Travis <jtra...@covalent.net>
Subject Re: PCRE symbols
Date Tue, 22 Aug 2000 22:49:10 GMT
Rasmus Lerdorf wrote:

> > The inclusion of the PCRE library within Apache 2.0 causes some
> > problems with other programs which also use PCRE.  mod_snake
> > is the one which immediately comes to mind.. ;-)
> >
> > Would it be possible to namespace protect the PCRE we use
> > in Apache, to avoid these collisions?  There are only a
> > handful of symbols which would need to be changed.
>
> I don't really like the idea of mangling these symbols that are part of a
> standard package.  Could you just make mod_snake smarter?
>
> Like the way we currently do it for PHP when it is built against Apache:
>
>     APXS_CFLAGS=`$APXS -q CFLAGS`
>     if `echo $APXS_CFLAGS|grep USE_HSREGEX>/dev/null`; then
>         APACHE_HAS_REGEX=yes
>     fi
>
> You are going to have to other such checks anyway.  Like checking for
> EAPI:
>
>     if `echo $APXS_CFLAGS|grep EAPI>/dev/null`; then
>        CPPFLAGS="$CPPFLAGS -DEAPI=1"
>     fi

I may not get exactly what you are saying, but it isn't really an option
to use Apache's PCRE, even if we knowingly select to do so.  The
reason is that generally the Python .py system libraries match up
with the PCRE and information compiled into the Python library.

To be more clear: Python .py files match up, and work with the libpython
and python binary.  This means that regex's in the .py system files
should match up with libpython.a.  If we override the PCRE functions
some regex's can fail, etc., so it is imperitive that Python modules always
get the PCRE that Python was installed with.

-- Jon



Mime
View raw message