#935 Move to pcre2

[Gwyn Ciesla]

Privoxy can only be compiled using pcre, which Fedora is deprecating as of Fedora 38 in favor of pcre2.

[Fabian Keil]

Thanks for the report.

This is also an issue for other distributions like Debian and migrating away from pcre is already on the todo list:
https://lists.privoxy.org/pipermail/privoxy-devel/2021-November/000502.html

[Roland Rosenfeld]

see also

• https://bugs.debian.org/999981 (pcre bug report in Debian)
• https://fedoraproject.org/wiki/PcreDeprecation

[gagan sidhu]

hi fabian,

i hate sourceforge but privoxy not having pcre2 support is driving me mad.

i know this will take more time than people think, given that you're using a custom match structure (pcrs_match) that cannot be accommodated with pcre2, which provides an opaque pcre2_data_match structure instead. i am not certain if the absence of pcre_extra is as-important, given that pcre2's equivalent of pcre_exec (pcre_match) no longer accepts this as an argument.

thankfully, i think you'll be able to use will rowe's patch from apache to make the transition much easier (https://github.com/apache/httpd/commit/c602ba14811ede722017c4e59e4e30d9990227b4).

i have provided my own shitty patch that's attached.

what makes me wonder if this patch may actually work (it compiles) is the ovector pointer variable.

since we allocate a pcre2_data_match structure (i assign it to a new variable, pcre2_matches), which presumably contains all of the matches from the pcre2_match call, i am curious if the ovector pointer variable (which i assign to outputs) enables analogous behaviour, since you're dumping the results of pcre_exec to outputs.

anyways, here's the patch. like i said, it's not perfect. i hate autoconf as well. but the fans of my firmware probably miss privoxy since everything else is on pcre2. so i thought i'd give it a try and i am hoping some of this stuff will help speed up the process.

[Fabian Keil]

The patch is currently discussed on the privoxy-devel@ list:
https://lists.privoxy.org/pipermail/privoxy-devel/2023-March/000610.html

[Geiger David]

Hi,

Mageia Linux also planned and started to drop old pcre library.

Regards,
David

[Fabian Keil]

Optional pcre2 support is available in the git master branch now.

[Gwyn Ciesla]

Works great on Fedora, thank you!

[Fabian Keil]

You're welcome. Thanks for testing and reporting back.

[Fabian Keil]

A regression introduced by the pcre2 support code was found and fixed in:
https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=e73b93ea9ad1f3e980bd78ed3ebf65dedbb598a2

A test was added in:
https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=87253c999d5628a6e9287bb0cc613d7b44bcec09

If you back-ported the pcre2 support code you may want to back port the regression fix as well.

The --disable-pcre2 flag didn't work as advertised either, but if you intend to use pcre2 anyway you may not care about the fix:
https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff;h=7fb978c74a8a46bd105d9f0ced92a4be0c9647e6

[Jakub Kulik]

Hi, I've hit several pcre2 related issues when building privoxy 4.0.0 on Solaris (where the header lives in a sub-directory). The configure script for pcre2/pcre2.h has the following issues:

• the inner header check (for pcre2/pcre2.h) is missing the PCRE2_CODE_UNIT_WIDTH define and hence always fails.
• the same check doesn't define HAVE_PCRE2 on success.

Here is the patch for the necessary changes:

--- privoxy-4.0.0-stable/configure.in
+++ privoxy-4.0.0-stable/configure.in
@@ -887,8 +887,8 @@ AC_CHECK_LIB(pcre2-8, pcre2_compile_8, [
       AC_EGREP_HEADER(pcre2_pattern_info, pcre2.h,[have_pcre2=yes; AC_DEFINE(HAVE_PCRE2)], [AC_MSG_WARN([[pcre2 old version installed]]); have_pcre2=no])
    ], [
       AC_CHECK_HEADER(pcre2/pcre2.h, [

-         AC_EGREP_HEADER(pcre2_pattern_info, pcre2/pcre2.h, [have_pcre2=yes; AC_DEFINE(PCRE2_H_IN_SUBDIR)], [AC_MSG_WARN([[pcre2 old version installed]]); have_pcre2=no])
-      ], [have_pcre2=no])
+         AC_EGREP_HEADER(pcre2_pattern_info, pcre2/pcre2.h, [have_pcre2=yes; AC_DEFINE(HAVE_PCRE2) AC_DEFINE(PCRE2_H_IN_SUBDIR)], [AC_MSG_WARN([[pcre2 old version installed]]); have_pcre2=no])
+      ], [have_pcre2=no], [#define PCRE2_CODE_UNIT_WIDTH 8])
    ], [#define PCRE2_CODE_UNIT_WIDTH 8])
 ], [have_pcre2=no])

Additionally, pcrs.h doesn't support include from pcre2/pcre2.h (PCRE2_H_IN_SUBDIR is not checked like in project.h).

We also have a third issue - on Solaris, we deliver the library into pcre/pcre2.h (directory is missing the 2), but that one seems a little bit more complicated to solve.

[Jakub Kulik]

Should I create a new bug, or is the report above sufficient?

[Fabian Keil]

Thanks for the report.

Please create a new bug report with a patch in git-format-patch format against git master if possible.