0

I am using PHP 5.6 on my centos-release-6-8.el6.centos.12.3.x86_64 server.

I got following error from one of my PHP function. 

Fatal error: Call to undefined function mb_detect_encoding()

So, I tried to install mbstring extension. when I execute 

sudo yum install php-mbstring

CLI returns 

Package php-mbstring-5.6.25-1.el6.remi.x86_64 already installed and latest version
Nothing to do

And I aslo tried "sudo yum install php56-mbstring" This returns

No package php56-mbstring available. Nothing to do

But still, PHP function giving me that error and there is no 'mbsting' in phpinfo()

I also add the following line to httpd.conf

LoadModule php5_module modules/libphp5.so

Server Restarted

Update:

[~]# php -v
PHP 5.6.22 (cli) (built: Jun 13 2016 11:43:51) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
[~]# php -m | grep mbstring
[~]# php -i | grep mbstring

Nothing returns to php -m | grep mbstring & php -i | grep mbstring

[~]# rpm -qil php-mbstring
Name        : php-mbstring                 Relocations: (not relocatable)
Version     : 5.6.25                            Vendor: Remi Collet
Release     : 1.el6.remi                    Build Date: Wed 31 Aug 2016 18:33:05 BST
Install Date: Mon 05 Sep 2016 16:26:05 BST      Build Host: builder.remirepo.net
Group       : Development/Languages         Source RPM: php-5.6.25-1.el6.remi.src.rpm
Size        : 2856446                          License: PHP and LGPLv2 and BSD and OpenLDAP
Packager    : http://blog.remirepo.net/
URL         : http://www.php.net/
/etc/php-zts.d/20-mbstring.ini
/etc/php.d/20-mbstring.ini
/usr/lib64/php-zts/modules/mbstring.so
/usr/lib64/php/modules/mbstring.so
/usr/share/doc/php-mbstring-5.6.25
/usr/share/doc/php-mbstring-5.6.25/libmbfl_LICENSE
/usr/share/doc/php-mbstring-5.6.25/oniguruma_COPYING
/usr/share/doc/php-mbstring-5.6.25/ucgendat_LICENSE

[~]# rpm -qa 'php*'
php-pecl-zip-1.13.4-1.el6.remi.5.6.x86_64
php-pecl-jsonc-1.3.10-1.el6.remi.5.6.x86_64
php-mbstring-5.6.25-1.el6.remi.x86_64
php-common-5.6.25-1.el6.remi.x86_64
Sadee
  • 101
  • 1
  • 1
  • 4
  • It would be useful to [edit] the question to include the output of `php -v` , `php -m | grep mbstring` and `php -i | grep mbstring`. – Anthony Geoghegan Sep 06 '16 at 10:01
  • @AnthonyGeoghegan : Updated with the results – Sadee Sep 06 '16 at 10:04
  • Interesting. Did you configure a third-party repo to install PHP 5.6? I would also add the output of `rpm -qa 'php*'` to the question. It might also be worth checking the output `rpm -qil php-mbstring` for anything unusual. – Anthony Geoghegan Sep 06 '16 at 10:15
  • @AnthonyGeoghegan : I have updated the result. there are mbsting.so in /usr/lib64/php-zts/modules/mbstring.so /usr/lib64/php/modules/mbstring.so But my extenstions path is: /usr/local/lib/php/extensions/no-debug-non-zts-20131226 And also: I have upgraded PHP 5.3 to 5.6 – Sadee Sep 06 '16 at 10:21
  • Output of `rpm -qa 'php*'`? – Anthony Geoghegan Sep 06 '16 at 10:23
  • @AnthonyGeoghegan : Updated with the result of rpm -qa 'php*' – Sadee Sep 06 '16 at 10:25
  • I thought there may be a possibility of different versions of PHP installed on your system but that's not the case. The only other thing I can think of is checking the contents of `/etc/php.d/20-mbstring.ini` to ensure that it contains `extension=mbstring.so`. – Anthony Geoghegan Sep 06 '16 at 10:35
  • @AnthonyGeoghegan : Yes there is "extension=mbstring.so". But I couldn't find any other PHP version remain. Will that be problem as I mentioned, my extension path is "/usr/local/lib/php/extensions/no-debug-non-zts-20131226". But there is no mbstring.so. – Sadee Sep 06 '16 at 10:40
  • @AnthonyGeoghegan : :O `rpm -ql php` returns 'package php is not installed' – Sadee Sep 06 '16 at 10:44
  • That extension directory doesn't sound right to me. [edit] the question to include the output of `php -i |grep ^extension_dir`. I think it should be `/usr/lib64/php/modules` (if not, you should find which php.ini file it has been changed in after verifying that the output of `ls /usr/lib64/php/modules` includes `mbstring.so`). – Anthony Geoghegan Sep 06 '16 at 10:49
  • @AnthonyGeoghegan : Yes It looks like abnormal path. Anyway, thats the path showing as PHP `extension_dir` path even in the phpinfo(). And there is a mbstring.so in the `/usr/lib64/php/modules`. I changed the module path, restarted. Then gave PDO not found from my PHP function. And still there is no mbstring in the phpinfo(). This looks like messed-up server config. I think its better to wiped-out existing PHP and reinstall as a fresh – Sadee Sep 06 '16 at 11:09

1 Answers1

2

Installing PHP extensions/modules via RPM will install the library files into /usr/lib64/php/modules/. Running php -i |grep ^extension_dir shows the extension directory that is currently configured.

An extension directory of /usr/local/lib/php/extensions/no-debug-non-zts-20131226 indicates that at some stage in the past, PHP was installed from source and that a php.ini file relating to this source installation is currently being used instead of the /etc/php.ini provided by the php-common package.

To solve this problem, you should remove the remnants of this source installation. Unfortunately, the Makefile provided with PHP source code doesn’t include an uninstall target so you can’t simply run make uninstall. I’d suggest using the find command to track down these files by their modification date.

Anthony Geoghegan
  • 3,761
  • 22
  • 41
  • I am highly appreciate your time & effort to this. However all of these configurations had done through EazyApache. (I got this to know after all of these tries) There are some unusual changes (rather doing directly on the server) because of installing/upgrades through EazyApache. So have to follow EazyApache to install new modules. Ref: https://forums.cpanel.net/threads/enable-install-mbstring-module.158165/ – Sadee Sep 06 '16 at 15:32
  • @Sadee That hurts! The fact that EazyApache was installed on the server was crucial information. Had you mentioned this vital fact in the question, we wouldn't have had to put so much effort into debugging. Shouldn't I get some reputation in return for spending all that time on you question? Now I know why cPanel questions were banned from [sf]. :( – Anthony Geoghegan Sep 06 '16 at 16:11