phpinfo is reporting incorrect pcre version

Question

I've spent the day trying to figure out a strange problem. I have a WordPress site that is running into the following error:

Warning: preg_replace() [function.preg-replace]: Compilation failed: unknown option bit(s) set at offset -1 in /path/to/public_html/wp-includes/shortcodes.php on line 257

That line in wp-includes/shortcodes.php is as follows:

$text = preg_replace("/[\x{00a0}\x{200b}]+/u", " ", $text);

I found this article that seemed to match up fairly well with my problem: http://labs.sasslantis.ee/2011/05/errors-in-wordpress-after-php-upgrade/

The article describes a situation in which there is different output of phpinfo(); in apache and on commandline with regard to libpcre

I verified that this is my issue by creating a test file with phpinfo(); in it and also ran the following from the shell:

php -r "phpinfo();"

The script (apache?) version returns PCRE Library Version 6.6 06-Feb-2006 The commandline version returns PCRE Library Version => 8.21 2011-12-12

I'm left wondering what to do. I'm not super well versed in command line usage, so I'm turning to you all hoping for some help.

The article mentions "fixing apache start-flags". I'm not sure what that means.

I've also found a comment somewhere else saying: "OK, it turned out that the problem was an older version of libpcre hanging around on the system and getting loaded by mistake. Once I updated to the latest version of libpcre, problem fixed." I'm not entirely sure how to vet this information on the server.

==== Edit 1 ====

I've have more information:

/opt/pcre/bin/pcretest -C

Returns

PCRE version 8.21 2011-12-12
Compiled with
UTF-8 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

This is not entirely surprising because we already know that the command line returns the correct version. But for some crazy unknown reason PHP, when run via the web, doesn't return the proper pcre values.

==== Edit 2 ====

I was tipped this article: http://www.bigboylemonade.com/pcre-version-problem-on-cpanel

Running pcretest -C without the full path returns:

PCRE version 6.6 06-Feb-2006
Compiled with
  UTF-8 support
  Unicode properties support
  Newline character is LF
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

I'm going to see what I can do about performing those last steps and will update shortly

Answer 1

Ok guys, I finally got the notes from my host about how they fixed the problem:

==================== Begin steps ==============================

when I started on this particular server, this was the data available:

[root@host2] ~ >> pcretest -C PCRE
version 6.6 06-Feb-2006
Compiled with
UTF-8 support
Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

[root@host2] ~ >> /opt/pcre/bin/pcretest -C PCRE
version 8.21 2011-12-12
Compiled with
UTF-8 support Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

Version 6.6 was also showing up in any phpinfo() webpage and also in php -i. By default in php versions >= 4.2, the Apache compile flag '--with-pcre-regex' is automagically included, so any EA run will use the 6.6. version that cPanel provides. The key to this was letting the OS know about the pcre libraries we want Apache to use, so the first step was to:

[root@host2] etc >> echo "/opt/pcre/lib/" >> /etc/ld.so.conf

Then running ldconfig -- now we have the libraries for both versions of PCRE available for the system users:

[root@host2] etc >> ldconfig -v | grep -i pcre
/opt/pcre/lib:
libpcre.so.0 -> libpcre.so.0.0.1
libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
libpcreposix.so.0 -> libpcreposix.so.0.0.0
libpcre.so.0 -> libpcre.so.0.0.1
libpcre.so.0 -> libpcre.so.0.0.1
libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
libpcreposix.so.0 -> libpcreposix.so.0.0.0
libpcrecpp.so.0 -> libpcrecpp.so.0.0.0
libpcreposix.so.0 -> libpcreposix.so.0.0.0
[root@host2] etc >>

Yay! Now, to tell Apache to use those instead of the 6.6 ones, use the handy rawopts file and rebuild Apache:

[root@host2] etc >> echo "--with-pcre-regex=/opt/pcre" >>
/var/cpanel/easy/apache/rawopts/all_php5 [[e-mail]] etc >>
/scripts/easyapache --build

When it's done, test it:

[root@host2] etc >> php -i | grep -i "pcre library" PCRE
Library Version => 8.21 2011-12-12 [[e-mail]] etc >>

[root@host2] ~ >> pcretest -C PCRE
PCRE version 8.21 2011-12-12
Compiled with
UTF-8 support
Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

[root@host2] ~ >> /opt/pcre/bin/pcretest -C PCRE
PCRE version 8.21 2011-12-12
Compiled with
UTF-8 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

========================== End ============================

Answer 2

In our case apache was not compiled using the --with-pcre parameter.
Pcre and pcre-devel was installed (from yum or apt repositories, no need to compile it), then we just had to locate pcre-config.
In our case it was /usr/bin/pcre-config, the 'bin' seems to be assumed by the apache compiler, so the final ./configure line had to include:
--with-pcre=/usr