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
