Re: Dynamically linking to pcre (was: Release date for Privoxy 3.0.19 stable)

Lee <[email protected]> wrote:

> On 12/30/11, Fabian Keil <[email protected]> wrote:
> > Lee <[email protected]> wrote:
> >
> >> On 12/29/11, Fabian Keil <[email protected]> wrote:
> >> > Lee <[email protected]> wrote:
> >
> >> >> Does the internal pcre version have modifications to handle the host
> >> >> part of regular expressions in the action files or is it two separate
> >> >> functions?  eg
> >> >> .example.com/
> >> >> matches any host name ending in ".example.com".  A normal [??] RE
> >> >> would treat the periods as match any single character.  Privoxy
> >> >> doesn't treat periods as wildcards until after a "/" character.
> >> >
> >> > No such modifications are necessary as Privoxy doesn't use
> >> > pcre for the host part of the URL pattern at all,
> >>
> >> ??
> >> It seems like it has to use something since it isn't a straight text
> >> match..
> >> Oh well, I'll try to follow the code & figure it out
> >
> > Have a look at host_matches() in urlmatch.c.
> 
> Thank you.  I took a quick look & it felt like learning string
> processing in assembler all over again.  I've got relatives visiting,
> so I doubt that I'll be able to seriously look at it for at least a
> week.

There's no need to hurry. 

> >> Where I was trying to go with the question was finding out if there's
> >> two separate packages - "host patterns" and whatever comes after the
> >> host part.  If it's all one package with modifications for matching
> >> host patterns then upgrading to the current PCRE libs + backporting
> >> Privoxy modifications to the library is going to be *much* harder.
> >>
> >> If it's two separate packages there's a slightly better chance I can
> >> figure out how to upgrade the windows version of Privoxy to the
> >> current pcre library.
> >
> > It should in theory work similar to the way the external
> > zlib is used:
> >
> > 1. Install a recent pcre version and its header files.
> > 2. Figure out a way to convince configure that a dynamic
> >    pcre version is available. It might work out of the box
> >    or require some fiddling.
> > 3. Get it to compile. Again, it might just work.
> > 4. Figure out a way to get the compiled binary working
> >    when installed from a package. This might require
> >    shipping a dll for pcre.
> 
> I'm using the cygwin 1.5 environment for building Privoxy.  I'll take
> another stab at upgrading to cygwin 1.7 cross-compiler in a week or
> two (cygwin dropped support for --enable-mingw32 when they released
> 1.7 and GCC 4.x, so to get a current pcre library I'm guessing that I
> need to figure out the cygwin cross-compile stuff or figure out how to
> use mingw)

Whatever pcre version is packaged for cygwin 1.5 is likely
to be a lot more recent than "our" version, so I think using
a more recent pcre version and using a more recent cygwin
environment are two separate problems that don't necessarily
have to be solved together.

Whatever method works to dynamically link to the pcre
version packages for cygwin 1.5 is likely to work for
later cygwin versions as well.

> > The alternative would be to update "our" pcre version
> > and to continue statically compiling pcre into the
> > Privoxy binary.
> 
> I'm assuming you've tried linking privoxy with the pcre library on
> your machine.  Did you have any issues with old action file regexs and
> new pcre libs?

I've been dynamically linking to the latest pcre version
ported to FreeBSD (currently 8.21) for several years now
and haven't noticed any issues with the action files.

Dynamically linking to a separately installed pcre version
has also been the default for most other packages since ages,
so most compatibility issues should be fixed already.

Of course we don't have a lot of test coverage for pcre,
so subtile issues might have slipped though the cracks.

> For example, I had a problem with regexs not working in awk after
> upgrading to cygwin 1.7  Turns out they enabled support for multiple
> languages in 1.7 and ranges like [a-z] didn't work until I set LANG=C

Unicode support in pcre has to be explicitly enabled which we
currently don't do.

Uncommon LANG values might still change the meaning of [a-z]
in the sense that a different alphabet might be used, but they
shouldn't stop working completely.

Fabian

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

_______________________________________________
Ijbswa-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ijbswa-developers

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

iEYEARECAAYFAk8AYgIACgkQSMVSH78upWPyZACfTqDtZ1uPcO/RR8ZQQKPx94z0
Hr8An0yjMopfhta4bJK56V22RDiu56rw
=yyQP
-----END PGP SIGNATURE-----