bug#21755: new snapshot available: grep-2.21.82-fbc5

[Bruce Dubbs]

Jim Meyering wrote:

> Thanks for testing.
> However, that failure probably indicates that you are running
> a binary that uses an older version of libpcre.  Compare the results
> of these commands on a Centos6 system:
>
>    $ gcc print-pcre-version.c -lpcre; ./a.out
>    7.8 2008-09-05
>    $ gcc print-pcre-version.c $(pcre-config --libs) \
>      -Wl,-rpath -Wl,$(pcre-config --prefix)/lib && ./a.out
>    8.37 2015-04-28
>    $ cat print-pcre-version.c
>    #include <stdio.h>
>    char *pcre_version(void);
>    int
>    main ()
>    {
>      puts (pcre_version());
>      return 0;
>    }

Thanks Jim,

I get:

$ gcc print-pcre-version.c -lpcre; ./a.out
8.37 2015-04-28

6 months old does not seem like an 'older' version to me.  Actually 
pcre2-10.10 is older than that.  There is one more recent version of 
pcre2-10.20 as of July 2nd.

> I.e., if I don't take special measures, I end up using the much
> older system-provided version than the one that I installed to
> work around this problem.
>
> I too saw the symptom of a segfault in "match", before I
> switched to building with these options:
>
>    make AM_CFLAGS="$(pcre-config --cflags)" AM_LDFLAGS="$(pcre-config
> --libs) -Wl,-rpath -Wl,$(pcre-config --prefix)/lib"

I'm not sure what advantage those switches would give.  I have

pcre-config --cflags = (null)
pcre-config --libs   = -lpcre
pcre-config --prefix = /usr

So that line would translate to:

make AM_CFLAGS= AM_LDFLAGS=-lpcre -Wl,-rpath -Wl,/usr/lib

which, if I'm not mistaken, is what the default would be without any 
options being passed to make.

The issue appears to be that there is a different pcre2 used by some 
distros.  I would think that the tests in grep should account for both 
pcre and pcre2, at least for a couple of years.

  -- Bruce