PHP cli

Hi,

I installed lang/php5 without the PHP cli:

Code:
# make showconfig
===> The following configuration options are available for php5-5.3.10_1:
     CLI=off "Build CLI version"
     CGI=off "Build CGI version"
     FPM=off "Build FPM version (experimental)"
     APACHE=on "Build Apache module"
     AP2FILTER=off " Use Apache 2.x filter interface (experimental)"
     DEBUG=off "Enable debug"
     SUHOSIN=on "Enable Suhosin protection system"
     MULTIBYTE=off "Enable zend multibyte support"
     IPV6=on "Enable ipv6 support"
     MAILHEAD=off "Enable mail header patch"
     LINKTHR=off "Link thread lib (for threaded extensions)"
===> Use 'make config' to modify these settings

My requirements changed, Cacti needs the PHP cli for polling. So I recompiled PHP with the following options:

Code:
# make showconfig
===> The following configuration options are available for php5-5.3.10_1:
     CLI=on "Build CLI version"
     CGI=off "Build CGI version"
     FPM=off "Build FPM version (experimental)"
     APACHE=on "Build Apache module"
     AP2FILTER=off " Use Apache 2.x filter interface (experimental)"
     DEBUG=off "Enable debug"
     SUHOSIN=on "Enable Suhosin protection system"
     MULTIBYTE=off "Enable zend multibyte support"
     IPV6=on "Enable ipv6 support"
     MAILHEAD=off "Enable mail header patch"
     LINKTHR=off "Link thread lib (for threaded extensions)"
===> Use 'make config' to modify these settings

I did so with:

Code:
# make
 [...]
# make deinstall
[..]
# make reinstall

Everything HTTPD side of things works just fine. But the CLI binary is acting strange or unfamiliar to me, it certainly isn't doing what it should for the Cacti poller.php.

Example:

Code:
[root@hesiod /usr/ports/lang/php5]# php
[root@hesiod /usr/ports/lang/php5]# php -v
[root@hesiod /usr/ports/lang/php5]# php -n -v
PHP 5.3.10 with Suhosin-Patch (cli) (built: Mar  3 2012 16:26:15) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
[root@hesiod /usr/ports/lang/php5]#

Am I missing something here?! Or why is the binary not working without '-n'

Any help greatly appreciated I was trying to get this working asap.

I've also tried portupgrade -Rrf php5-5.3.10_1 and still no joy.
 
What have you got in your INI file? -n loads PHP without INI so there much be something over there that's causing you problems.
 
Yeah that's just it, with no php.ini I still had the same problem. I have figured out where the problem was but not why. I had to remove the pdo_sqlite and sqlite3 extensions. No idea why but there you go. The urgency right now was to fix the problem. I plan to revisit the issue at another time and see if I can replicate this.

Thanks for the reply anyway.
 
Were you able to revisit this issue and replicate it? I'm encountering exactly the same problem and have tried the solution presented in this thread. I've tried the default php.ini-production as php.ini with the same result (need php -n for cli).

Code:
web01# uname -a
FreeBSD web01 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Jan 30 23:32:57 EST 2012
    root@web01:/usr/obj/usr/src/sys/GENERIC  amd64

web01# php -v
web01# php -n -v
PHP 5.3.10 with Suhosin-Patch (cli) (built: Mar  6 2012 15:01:58)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
 
Well, it took me posting on here to figure it out (to get it working). Not only did I have to remove the pdo_sqlite and sqlite3 extensions, but also the apc extension, which is surprising as APC is now being supported and integrated into PHP by the development team, isn't it?
 
Hi,

Apologies for not getting back sooner. No I haven't tried to replicate this problem yet. I might try to do so tonight if I get a chance. I can spin up a quick VM for testing. I'm not sure if some extensions are mutually exclusive or not, or if I I am Doing It Wrongâ„¢ I've only run into this problem with FreeBSd 9.0 and never with 8.x Since some things (might?) have changed in FreeBSD 9.0 that I am not familiar with I need to test and read more before I hassle and waste anyone's time. Although I can't find anything in /usr/ports/UPDATING to suggest that we have done something wrong.
 
Back
Top