Upgrade to pcre2 version 10.31.
Bug: N/A
Test: builds and boots, getprop -Z works
Change-Id: I2fbda9427edc9e5d966333a567b50539e17ed48d
diff --git a/dist2/NON-AUTOTOOLS-BUILD b/dist2/NON-AUTOTOOLS-BUILD
index ceb9245..0775794 100644
--- a/dist2/NON-AUTOTOOLS-BUILD
+++ b/dist2/NON-AUTOTOOLS-BUILD
@@ -1,10 +1,6 @@
Building PCRE2 without using autotools
--------------------------------------
-This document has been converted from the PCRE1 document. I have removed a
-number of sections about building in various environments, as they applied only
-to PCRE1 and are probably out of date.
-
This document contains the following sections:
General
@@ -49,7 +45,7 @@
macro settings that it contains to whatever is appropriate for your
environment. In particular, you can alter the definition of the NEWLINE
macro to specify what character(s) you want to be interpreted as line
- terminators.
+ terminators by default.
When you compile any of the PCRE2 modules, you must specify
-DHAVE_CONFIG_H to your compiler so that src/config.h is included in the
@@ -95,8 +91,10 @@
pcre2_compile.c
pcre2_config.c
pcre2_context.c
+ pcre2_convert.c
pcre2_dfa_match.c
pcre2_error.c
+ pcre2_extuni.c
pcre2_find_bracket.c
pcre2_jit_compile.c
pcre2_maketables.c
@@ -123,10 +121,14 @@
Note that you must compile pcre2_jit_compile.c, even if you have not
defined SUPPORT_JIT in src/config.h, because when JIT support is not
configured, dummy functions are compiled. When JIT support IS configured,
- pcre2_compile.c #includes other files from the sljit subdirectory, where
- there should be 16 files, all of whose names begin with "sljit". It also
- #includes src/pcre2_jit_match.c and src/pcre2_jit_misc.c, so you should
- not compile these yourself.
+ pcre2_jit_compile.c #includes other files from the sljit subdirectory,
+ all of whose names begin with "sljit". It also #includes
+ src/pcre2_jit_match.c and src/pcre2_jit_misc.c, so you should not compile
+ these yourself.
+
+ Not also that the pcre2_fuzzsupport.c file contains special code that is
+ useful to those who want to run fuzzing tests on the PCRE2 library. Unless
+ you are doing that, you can ignore it.
(5) Now link all the compiled code into an object library in whichever form
your system keeps such libraries. This is the basic PCRE2 C 8-bit library.
@@ -174,26 +176,18 @@
(11) If you want to use the pcre2grep command, compile and link
src/pcre2grep.c; it uses only the basic 8-bit PCRE2 library (it does not
- need the pcre2posix library).
+ need the pcre2posix library). If you have built the PCRE2 library with JIT
+ support by defining SUPPORT_JIT in src/config.h, you can also define
+ SUPPORT_PCRE2GREP_JIT, which causes pcre2grep to make use of JIT (unless
+ it is run with --no-jit). If you define SUPPORT_PCRE2GREP_JIT without
+ defining SUPPORT_JIT, pcre2grep does not try to make use of JIT.
STACK SIZE IN WINDOWS ENVIRONMENTS
-The default processor stack size of 1Mb in some Windows environments is too
-small for matching patterns that need much recursion. In particular, test 2 may
-fail because of this. Normally, running out of stack causes a crash, but there
-have been cases where the test program has just died silently. See your linker
-documentation for how to increase stack size if you experience problems. If you
-are using CMake (see "BUILDING PCRE2 ON WINDOWS WITH CMAKE" below) and the gcc
-compiler, you can increase the stack size for pcre2test and pcre2grep by
-setting the CMAKE_EXE_LINKER_FLAGS variable to "-Wl,--stack,8388608" (for
-example). The Linux default of 8Mb is a reasonable choice for the stack, though
-even that can be too small for some pattern/subject combinations.
-
-PCRE2 has a compile configuration option to disable the use of stack for
-recursion so that heap is used instead. However, pattern matching is
-significantly slower when this is done. There is more about stack usage in the
-"pcre2stack" documentation.
+Prior to release 10.30 the default system stack size of 1Mb in some Windows
+environments caused issues with some tests. This should no longer be the case
+for 10.30 and later releases.
LINKING PROGRAMS IN WINDOWS ENVIRONMENTS
@@ -375,18 +369,19 @@
z/OS and z/VM are operating systems for mainframe computers, produced by IBM.
The character code used is EBCDIC, not ASCII or Unicode. In z/OS, UNIX APIs and
applications can be supported through UNIX System Services, and in such an
-environment PCRE2 can be built in the same way as in other systems. However, in
-native z/OS (without UNIX System Services) and in z/VM, special ports are
-required. For details, please see this web site:
+environment it should be possible to build PCRE2 in the same way as in other
+systems, with the EBCDIC related configuration settings, but it is not known if
+anybody has tried this.
- http://www.zaconsultants.net
+In native z/OS (without UNIX System Services) and in z/VM, special ports are
+required. For details, please see file 939 on this web site:
-The site currently has ports for PCRE1 releases, but PCRE2 should follow in due
-course.
+ http://www.cbttape.org
-You may also download PCRE1 from WWW.CBTTAPE.ORG, file 882. Everything, source
-and executable, is in EBCDIC and native z/OS file formats and this is the
-recommended download site.
+Everything in that location, source and executable, is in EBCDIC and native
+z/OS file formats. The port provides an API for LE languages such as COBOL and
+for the z/OS and z/VM versions of the Rexx languages.
-=============================
-Last Updated: 16 July 2015
+===============================
+Last Updated: 13 September 2017
+===============================