|
From: | Bruce Dubbs |
Subject: | Re: [platform-testers] bug#21755: new snapshot available: grep-2.21.82-fbc5 |
Date: | Sun, 25 Oct 2015 17:19:26 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 |
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-286 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/libwhich, 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
[Prev in Thread] | Current Thread | [Next in Thread] |