Problem with PHP cli

filbar · n00b Joined: 23 Nov 2005 Posts: 11

I have from sime time problem with PHP cli interface. When I call PHP I have this error:

/usr/bin/php: error: `/usr/lib64/php5.5/bin/.libs/php' does not exist
This script is just a wrapper for php.
See the libtool documentation for more information.

I have PHP installed as:
[ebuild R ] dev-lang/php-5.5.15:5.5 USE="apache2 berkdb bzip2 calendar cgi cli crypt ctype curl exif fileinfo filter ftp gd gdbm gmp hash iconv
imap intl ipv6 json ldap mysql mysqli nls opcache pdo phar posix readline session simplexml soap spell sqlite ssl sysvipc tokenizer truetype unicode xml
xmlreader xmlrpc xmlwriter xpm xslt zip zlib -bcmath -cdb -cjk -debug -embed -enchant (-firebird) -flatfile -fpm (-frontbase) -inifile -iodbc -kerberos
-ldap-sasl -libedit -libmysqlclient -mhash -mssql -oci8-instant-client -odbc -pcntl -postgres -qdbm -recode (-selinux) -sharedmem -snmp -sockets
(-sybase-ct) -systemd -threads -tidy -wddx" 0 kB

What I have wrong?

miket · Posted: Mon Oct 06, 2014 3:09 pm Post subject:

I think the symlink might be wrong. Try

filbar · n00b Joined: 23 Nov 2005 Posts: 11

This was a first thing what i make.

miket · Posted: Tue Oct 07, 2014 7:00 pm Post subject:

Pardon me if I didn't quite understand your answer. Do you mean to say that you tried to do the eselect when you first had the problem?

To further clarify the issue, let's see if the CLI executable for PHP 5.5 is where it is supposed to be and acts correctly. Try running this command:

filbar · n00b Joined: 23 Nov 2005 Posts: 11

This give me me the message:

miket · Posted: Sat Oct 18, 2014 2:32 am Post subject:

Ohh my. I don't know how your system could get into such a state, but there it is. I had never known that libtool could make little wrapper scripts like that. I infer from "cannot be directly executed until all the libtool libraries that it depends on are installed" that you have dependencies that are missing or at the wrong revisions.

My impression is that what your system needs is a good revdep-rebuild. Newer versions of Portage are supposed to reduce the need for it, but I think you're in one of those tricky situations now where it is still necessary.

If you don't already have gentoolkit installed, you'll have to take care of that first:

filbar · n00b Joined: 23 Nov 2005 Posts: 11

This is the think which I do after every update. Now I try unmerge and emerge PHP again, but the php CLI don't works. The funniest think is that all other gentoo and portage works well and mod_php too, then only broken is php cli and cgi.
I don't know how libtool works and how can I debug why is wrapper script installed instead of real php cli and cgi.

miket · Posted: Mon Oct 20, 2014 3:16 am Post subject:

This is perplexing. I do have one theory at the moment. Maybe this might hold the solution: emerge's treatment of file collisions.

You know how Portage sometimes complains that a package contains files to be installed that seem not to be from previous versions of a package but were put there some other way? Portage tries to identify the packages in such a case, but it can't always do so. When libtool (or lafilefixer maybe) replaced that /usr/lib64/php5.5/bin/php it may have made it so that emerge would not remove it when you unmerged PHP, but then when you re-merged the package, there was a collision which emerge resolved by not overwriting the existing file.

It seems like this is shooting in the dark, but it does leave you something to try: unmerge php:5.5, check whether that odd libtool-generated script is still there, remove it if so, and then re-merge php.

For reference, here are the executable files (include .so's) I have installed for PHP 5.5. I've got the fpm USE flag instead of cgi (hence php-fpm; I was trying it out), but your files ought to be similar: