Re: pcre 8.37 with latest patches won't build

Hi,

sorry, this is not your fault. I fucked that up.

I was sure that these patches built but clearly I did something wrong.

I reverted the commit so that you can pull and resume your build and will then upload a new commit after I fixed this.

Thanks for the notice.

Best, -Michael

On Wed, 2015-08-19 at 20:47 +0200, Matthias Fischer wrote:

Hi,

yesterday I tried to build the latest 'next', but it failed. It couldn't apply 'pcre-8.37-Fix-another-buffer-overflow.patch':

***SNIP*** Aug 18 19:03:54: Building pcre pcre-8.37.tar.gz checksum OK

• cd /usr/src/lfs
• make -f pcre LFS_BASEDIR=/usr/src install

====================================== Installing pcre-8.37 ... Install started; saving file list to /usr/src/lsalr ... cd /usr/src/pcre-8.37 && patch -Np1 < /usr/src/src/patches/pcre-8.37-Fix-buffer-overflow-for-named -recursive-back-referen.patch patching file pcre_compile.c patching file testdata/testinput2 patching file testdata/testoutput2 cd /usr/src/pcre-8.37 && patch -Np1 < /usr/src/src/patches/pcre-8.37-Fix-buffer-overflow-for-forward -reference-within-bac.patch patching file pcre_compile.c patching file testdata/testinput2 patching file testdata/testoutput2 cd /usr/src/pcre-8.37 && patch -Np1 < /usr/src/src/patches/pcre-8.37-Fix-another-buffer-overflow.patch patching file pcre_compile.c Hunk #1 FAILED at 7210. 1 out of 1 hunk FAILED -- saving rejects to file pcre_compile.c.rej patching file testdata/testinput2 patching file testdata/testoutput11-16 patching file testdata/testoutput11-32 patching file testdata/testoutput11-8 patching file testdata/testoutput2 make: *** [/usr/src/log/pcre-8.37] Error 1 ***SNAP***

'pcre_compile.c.rej' says:

***SNIP*** --- pcre_compile.c +++ pcre_compile.c @@ -7210,7 +7210,12 @@ real compile this will be picked up and the reference wrapped with OP_ONCE to make it atomic, so we must space in case this occurs. */

•      if (recno == 0) *lengthptr += 2 + 2*LINK_SIZE;
  

•      /* In fact, this can happen for a non-forward reference
  

because

•      another group with the same number might be created later.
  

This

•      issue is fixed "properly" in PCRE2. As PCRE1 is now in 
  

maintenance

•      only mode, we finesse the bug by allowing more memory
  

always. */

•      /* if (recno == 0) */ *lengthptr += 2 + 2*LINK_SIZE;
        }
  
      /* In the real compile, search the name table. We check the
  

name ***SNAP***

Deleting this section didn't help. Anyone else or my fault?

Regards Matthias