CiviCRM Community Forums (archive)

The version number is (mostly) irrelevant. It's whether the package was compiled with unicode support or not. So:

1) If you don't mind the warnings, things should still work.

2) You should be able to use the one given in the link.

3) It could. Can't say without knowing what else is on that server. Seems unlikely though. Running that rpm command should give you a warning if there's some kind of package dependency mismatch. Add the --test flag if you want to see dry run output.

Thanks for the responses. Hmmm...

1. Is there any way that the PCRE libary/Unicode issue could possibly cause CiviContribute to, say, take a donor straight from the donation form/info verification page directly to the "thank you/order completed" page without going to the PayPal payment page in between?? I ask because this is the only actual usage issue I've had with CiviCRM since the upgrade (and it's only happened twice out of a dozen donations, which seems odd).

See http://forum.civicrm.org/index.php/topic,12721.0.html for the details...

2. I'm not sure what the download directory path is for my current installation of PCRE, and doing a search in terminal has been frustrating...any easy way of knowing where it would be located?

3. MediaTemple *did* give me step-by-step instructions for updating to the latest version (8.01). Any way of knowing whether or not it has Unicode support right out of the box?

1. Replace the offending lines like I mentioned earlier in this thread and if you are still getting the problem then that would indicate the contribute problem is not related to the unicode issue.

2. rpm -q -l pcre

3. Can't think of a quick way. Maybe the wrong forum - ask the pcre community. Or if you have even a regular fedora machine for testing you could install and check it there probably.

Thanks! Well, I tried the rpm -q -l pcre command, and this is what it kicked back:

/lib/libpcre.so.0
/lib/libpcre.so.0.0.1
/usr/bin/pcregrep
/usr/bin/pcretest
/usr/lib/libpcrecpp.so.0
/usr/lib/libpcrecpp.so.0.0.0
/usr/lib/libpcreposix.so.0
/usr/lib/libpcreposix.so.0.0.0
/usr/share/doc/pcre-6.6
/usr/share/doc/pcre-6.6/AUTHORS
/usr/share/doc/pcre-6.6/LICENCE
/usr/share/man/man1/pcregrep.1.gz
/usr/share/man/man1/pcretest.1.gz
So I'm guessing that it's either simply /lib or /usr/lib ??

As for testing out the "skipping PayPal" mystery, that'll probably take some time to ferret out, because it worked properly several times, then that happened twice--then worked properly several more times afterwards, so there doesn't seem to be any way of being sure whether it's fixed or not other than to see if it happens again at some point in the future.

Just how risky would it be to simply swap out the code per your earlier suggestion? I tried it briefly, and sure enough the warning messages seem to have gone away, but have changed it back for now. The site *is* live/public, FWIW.

This is a compile WARNING, not an error.  If we suppress warnings, then messages will not appear.  What are the consequences of NOT recompiling with PCRE, besides having to look at these warnings?

The documentation for installing CiviCRM v3.4 points to this thread. Thought I'd update this for further information on CentOS installations.

The default PCRE package is NOT compiled with Unicode Properties Support (on x86_64). Check by executing pcretest -C.
A simple update to CentOS using the default repositories should update PCRE with Unicode Properties Support. Preferable as this ensures that the package is tested and works correctly.
Check with yum list installed | grep pcre
Check available with yum list available | grep pcre
Update all with yum update
Update PCRE with yum update pcre

After update check by executing pcretest -C.

Should I update the documentation?