i got this error message after installation:

warning: preg_match() [function.preg-match]: Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0 in /home/sample/www/sample.com/drupal/includes/unicode.inc on line 32.

i've checked and PCRE on my server it says it's working fine.

i deinstall and reinstall PCRE but still got the error. i run pcretest - C and it seems to work here:

Compiled with
UTF-8 support
Unicode properties support
Newline sequence is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

can anyone offer some help?

Comments

chx’s picture

but at least old pcre library.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A teddy bear is a cuddle with four paws on the end.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

broncos88’s picture

what did you mean? can you please explain more?

chx’s picture

We need PCRE library version 4.3 at least, this comes bundled with PHP 4.3.3, but if you are not using the library that comes with PHP, then that's irrelevant. You gave us zero information on the OS, version of the PCRE package and PHP version you use. It's hard to help without these.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A teddy bear is a cuddle with four paws on the end.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

broncos88’s picture

freeBSD: 6.0
mysql: 4.1.21
PHP: 5.1.5
PCRE version 6.7 04-Jul-2006

Juan Carlos’s picture

Hello broncos88,

I got exactly the same problem, I followed the instructions as in node http://drupal.org/node/41214

I removed the 6.7 package and reinstall from ports with the pcre-utf8 support but without any luck.

Same configuration with vps3 server freebsd 6.x.

The only different thing that I made was installed first php5, and then php4, not sure if I needed to remove php5 and that is affecting in some way.

Regards,
Juan

broncos88’s picture

did you mean you got it worked now?

i followed the instruction there too but it is not working.

i uninstall php5 and installed php4 but i still got the same error. it is now back to php5 and still searching for help...

Juan Carlos’s picture

I sent an email to verio support to help me on this, since I don't know if this is a server issue.

But still i'm waiting for a response.
Juan

broncos88’s picture

i did the same thing but i doubt they would help since they would say this is third party installation therefore there will not be any support but then you never know, please let me know.

Juan Carlos’s picture

Regarding the problem I found this
http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2006-November/1050...

I'm not an expert on freebsd but I think this is a bug.

Also tried the following...

After reinstall the pcre, went to ports and installed again from there but with the option Make WITH_UTF8=yes , can you please try if this works for you?, unfortunally I'm getting the same error :(

Saludos,
Juan

broncos88’s picture

nothing is working. still got the same error. verio replied and sent me to the same link you mentioned. they said it is software problem and they don't provide support.

can somebody offer some help here? i know i found one post on drupal website where i can modify unicode.txt as a temporarily solution. i can't find this post now.

Juan Carlos’s picture

Do you know how to compile php from source?

One last thing I need to check is to compile php from source, and
explicity compile PHP with its own internal implementation of PCRE; (remove
the --with-pcre-regex option from php's compile step), but I don't know how
to acomplish this.

broncos88’s picture

i've read that too but i am still trying to figure out how to.

broncos88’s picture

can anyone offer some help please? if you would like, you can have access to the server. the server is at verio and it's VPS3. i've tried and done all solutions that i can find on drupal about this problem but nothing is working, the error is still there:

warning: preg_match() [function.preg-match]: Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0 in

i've checked pcre and it is installed and UTF-8 i supported

PCRE version 6.4 05-Sep-2005
Compiled with
UTF-8 support
Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Match recursion uses stack

here is my server:
freebsd 6
php version 4.4.4
mysql version 4.1.21

snarkyFish’s picture

I'm having the same problem.. verio vps3.. i've tried php 4.4.4 and php5 with no luck. when i use their vinstall utility to install php5 with pcre as an option, i get the pretty drupal warning mentioned above, when i don't install that, it fails hard with things like:
"Fatal error: Call to undefined function preg_replace_callback()"

people have suggested recompiling php from source, but i don't really know how to do that. I contacted verio support and they say their support responsibility ends at their vinstall utility.

please help.. if you can lend some knowledge to point us in the right direction.

chx’s picture

This is not a Drupal issue. Educate yourself about the OS you use. http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/093343.html
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

snarkyFish’s picture

As far as i can tell, the post you linked says that freebsd uses modules and doesn't compile pcre at installation.. but drupal is checking for compilation? My other preg code works just fine.. so.. that seems like it is a drupal problem.. drupal is looking for the wrong thing?

I really don't care if drupal has utf8 support or not, i just want a blog to work and get on with my day.. Drupal seems to be working ok otherwise, and this is a 'warning' so how about we just turn the damned thing off? workarounds?

We all have things we don't know, you just don't believe yours exist. Help some people out.. instead acting like they're stupid.

tkjoffs’s picture

I was looking to switch to Drupal from another CMS, and am having the same issues. Now with the Jerk above telling me that this is not a Drupal issue when every other script I have ever run that uses PCRE has woked, I am pretty well done with Drupal. I decided that I would give it a go because so many educational groups rave about it. Sorry to say that this is just not a well enough developed application to not support true cross-platform scenarios, especially when the platform that they do not support is the number one used OS for web hosting in the world, FreeBSD. Perhaps someone needs to pull their smart mouth out of their dark recesses and appologise to the community. Especially since I have contributed to this Open Source project in the form of cash and I am sure others would have in time, if not already!

tunesmith’s picture

I just came across this with exactly the same problem and I'm disappointed in the responses so far - basically we're dead in the water unless we compile php from scratch? Same situation for me, verio, vps3, drupal5, php5, pcre6.4 with utf8, and an error message that won't go away.

Any way of fixing this or inhibiting the error message?

gein’s picture

There seems to be an issue with PHP 5.2.1 and PCRE on FreeBSD system (I'm running FBSD 6.2). I have seen solutions where PCRE has been downgraded from 7 to 6.6.1 and I will try that out right now and see if it solves this issue for me.

edit/
I went to fast. The error I got was something like: preg_replace_callback() [function.preg-replace-callback]: Compilation failed: lookbehind assertion is not fixed length at offset 5
which could be fixed by downgrading PCRE.

Boletus’s picture

There is a bug in the PCRE library that comes to life with PHP 5.2.1. The solution was to downgrade PCRE from 7.0 to an older version.

This seems to have taken care of my problem. Touch wood...

freeunixer’s picture

I already downgrade
php from 5.2.1 -> 5.2.0
pcre from 7.0.1 -> 6.6_1
from my FreeBSD 6.1

but the error message still show on
Fatal error: Call to undefined function preg_replace_callback() in /drupal/includes/database.inc on line 196

how can i do now?

every time i upgrade php, than drupal bomb -_-

figaro’s picture

I have solved many other problems on my FreeBSD 6.2 machine when deinstalling pcre 6.6_1 and installing pcre-utf8 instead. Hope this offers a pointer to someone.

andremolnar’s picture

I was experiencing similar preg_* compilation failed: lookbehind assertion is not fixed length at offset x - errors at Verio (freeBSD).

I checked my phpinfo - and had php 5.1.2 with PCRE 6.7

I portupgraded php5 to php 5.2.2

I portupgraded pcre (said it was up to date at 7.1)

I checked my phpinfo again - and had php 5.2.2 **with PCRE 6.7**

Solution:
cd /usr/ports/devel/php5-pcre
make
make install
make clean

apachectl restart

A check of phpinfo - php 5.2.2 with PCRE 7.1
All problems went away.

So - check to see that PHP is using the latest version of PCRE - if not install the appropriate port

andre

Anonymous’s picture

PHP comes with its own pcre library. Specifying --with-pcre-regex=/path/to/pcre disables the PHP internal library. For what ever reason not using the internal library causes this issue.

Earnie -- http://for-my-kids.com

emdog4’s picture

the --with-pcre-regex=/usr is common with standard (distro) php installs, and most likely your php install was compiled with it. you can check what flags were used by running phpinfo();

compiling php from source is NOT hard. download the source, ./configure, make, make check, and (as root) make install. it will take 30-45 minutes depending on your computer, but its really easy to do, especially if you know whats already installed on your system. (you shouldn't need to delete the existing install beforehand)

here are the flags that i have passed to the compiler: (all on one line, FOR REFERENCE ONLY)
./configure --prefix=/usr \
--sysconfdir=/etc \
--with-apxs2 \
--enable-force-cgi-redirect \
--enable-discard-path \
--enable-fastcgi \
--with-config-file-path=/etc \
--with-openssl \
--with-pcre-regex=/usr \
--with-zlib \
--enable-bcmath \
--with-bz2 \
--enable-calendar \
--with-curl \
--with-curlwrappers \
--enable-dba=shared \
--enable-exif \
--enable-ftp \
--with-openssl-dir=/usr \
--with-gd=/usr \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-zlib-dir=/usr \
--with-freetype-dir=/usr \
--with-gettext \
--with-gmp \
--enable-mbstring \
--with-mysql \
--with-mysql-sock=/var/run/mysql \
--with-ncurses \
--with-pdo-mysql \
--with-pspell \
--with-readline \
--enable-sockets \
--with-xsl \
--with-iconv \
--enable-dba \
--with-mcrypt=/usr \
--with-mhash=/usr

(i'm using PHP-5.2.6, Apache 2.2.2, mySql 5.0.21, and the Linux 2.6.22.5 kernel)

Anyways, I had this same problem installing MediaWiki, and a google search led me here. I am pretty sure its a problem with PCRE, and it seems like it might be able to be fixed in the Drupal code with a work around. I think the easiest solution, however, would be to recompile php. I'll try this now, and post my results.

here a a link to the LFS documentaion for PCRE:

http://www.linuxfromscratch.org/blfs/view/svn/general/pcre.html

thanks!
Emery

---
rm /bin/laden

cyberscribe’s picture

Hi Gang,

I ran into this when trying to install Drupal 6.4 on RHEL 4 (kernel 2.6.9-67.0.20.ELsmp), which runs PHP 4.3.9 compiled with --with-pcre-regex=/usr.

Basically, there are two lines in two files that are coughing up warnings:
include/bootstrap.inc line 723:

return (preg_match('/^./us', $text) == 1);

and include/unicode.inc line 47:

if (preg_match('/[à-á]/u', 'â')) {

both lines are attempting to check for unicode support, but the problem is that if they fail, PHP coughs up a warning, and that warning in turn conflicts with header output already sent, which causes the install script to stop.

Fortunately, the fix is simple:

change include/bootstrap.inc line 723:

return (@preg_match('/^./us', $text) == 1);

and change include/unicode.inc line 47:

if (@preg_match('/[à-á]/u', 'â')) {

the @ will suppress the warnings, preventing the domino-effect that stops the installer.

After these two changes, I noticed some of the descriptions for fields in the web-based installer, and the submit button value, were missing. So, I manually edited the settings.php file to taste, and am now checking for any other implications of using the default PCRE in our configuration. So far, it mostly seems to be working, but may require additional tweaking.

[EDIT: there are too many problems (see below) -- these warnings are not just cosmetic]

Hope that helps someone.

Cheers,
Robert

cyberscribe’s picture

I take it back ... even suppressing the warnings, there are just too many problems with this manner of installation. Apparently utf-8 support is required for a functional site, even though it is not listed at:

http://drupal.org/requirements

going to see if I can get PCRE to play nicely now...

cyberscribe’s picture

In the end, I had to resort to:

strace httpd -X 2>&1 | grep pcre

to tell me the order of precedence Apache was using to try to find the pcre modules. Just beacuse pcretest -C said UTF-8 support was compiled in didn't necessarily mean that Apache was looking at the same library (per se). Good luck to any of the rest of you still struggling to get a UTF-8-enabled PCRE library to get picked up by apache/libphp - it really shouldn't be this hard!

totocol’s picture

It worked for me. I'm a newbi so I just want to see it installed and then I will try to fix the PCRE thing later. Only have only error left:

Fatal error: Call to undefined function: file_get_contents() in c:\foxserv\apache\test\includes\common.inc on line 3414

Any ideas?

Totocol

Les Lim’s picture

Apparently a FreeBSD update on Dec 7. 2008 caused this error to pop up with drupal installations on those servers. Here's an article:

http://jake.wyrr.org/content/fix-pcre_utf8-errors-in-drupal-sites-hosted...

Here's the text of it, in case that link fails:

By Jake | December 7, 2008

On December 7th, 2008, the FreeBSD port devel/php5-pcre was integrated into the php 5.2.7 base. Once that happened, many people who run Drupal-based sites on top of FreeBSD’s latest PHP5 saw error messages reading:

“PHP Warning: preg_match(): Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0″

…repeating almost endlessly on their site. This was caused by Apache defaulting to its built-in PCRE module, which is very out-dated and does not provide UTF-8 support. Luckily, this is a relatively easy fix.

First, stop Apache:

/usr/local/etc/rc.d/apache22 stop

Next, uninstall Apache and tell it to use devel/pcre instead of its own bundled module:

cd /usr/ports/www/apache22; make deinstall; make config
Apache PCRE

Select 'Use devel/php5-pcre instead of bundled one'

Re-install Apache:

make install clean

Check to see if the installer re-started Apache for you:

/usr/local/etc/rc.d/apache22 status

Finally, start Apache if it’s not already running:

/usr/local/etc/rc.d/apache22 start

Enjoy your Drupal site!
Thomas Sewell’s picture

A related error as the result of a recent set of port upgrades on FreeBSD:
PHP Fatal error: Call to undefined function preg_replace_callback() in /data/www/drupal-5.2/includes/database.mysql.inc on line 318

Also:

$ echo "<?php phpinfo ?>" | php
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/pcre.so' - /usr/local/lib/php/20060613/pcre.so: Undefined symbol "php_pcre_free" in Unknown on line 0

I had recently upgraded the php, pcre, and apache ports all at the same time with portupgrade. Apparently the default dependency resolution during the upgrades didn't rebuild pcre.so at the right time.

The solution I reached was:

cd /usr/ports/devel/php5-pcre
make deinstall
make clean
make install
apachectl stop
apachectl start

Hope that helps someone else.

Bensbury’s picture

Not sure if this helps but I had a similar error:

My studio manager added this to the htaccess file

php_value output_buffering "Off"
php_value mbstring.language "neutral"
php_value mbstring.encoding_translation "Off"
php_value mbstring.http_input "pass"
php_value mbstring.http_output "pass"
php_value mbstring.internal_encoding "UTF-8"
php_value mbstring.substitute_character "none"
php_value mbstring.func_overload "none"
php_value mbstring.detect_order "UTF-8,EUC-JP,SJIS,JIS,ASCII,UTF-16"

Then it worked.

otiecoyote’s picture

I'm not a drupie, but this list had the most informative information I found about the PCRE and UTF8 error.

My `pcretesting -C` output said I had 6.6 installed with UTF-8 support, but the phpinfo() output confirmed what others said above about apache having it's own PCRE build.. mine was 5.3 something.. and that it did not have utf8 enabled. I tried recompiling PCRE from the Apache source files (mine: /usr/src/httpd-2.2.14/srclib/pcre) but could never get it to work. (Makefile had a ${top_srcdir} of /build/*, but that variable was never set, so it never 'make'd) anyway...

I tried several things, but the following finally worked... (Centos Distribution... pcre binaries were in /usr/bin, pcre lib files were in /usr/include... trial and error gave me the --with-pcre=/usr configuration below)

- in my apache source folder (mine: /usr/src/httpd-2.2.14/) I did a make clean
- looked at the config.log file made from my last apache compile:
...
$ ./configure --enable-ssl --enable-dav --enable-so
...

- ran the command ./configure --enable-ssl --enable-dav --enable-so --with-pcre=/usr
- then make && make install

no more PCRE errors at the same point I had them before.