configure command line missing from phpinfo

Bug #516061 reported by Dominik
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
php5 (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Binary package hint: php5

php -i doesn't show any information on the exact configure command line used to build PHP

Normally, php -i should contain a line starting with 'Configure Command'

System info is:
# lsb_release -rd
Description: Ubuntu 9.10
Release: 9.10

# apt-cache policy php5-common
php5-common:
  Installed: 5.2.10.dfsg.1-2ubuntu6.4
  Candidate: 5.2.10.dfsg.1-2ubuntu6.4
  Version table:
 *** 5.2.10.dfsg.1-2ubuntu6.4 0
        500 http://us.ec2.archive.ubuntu.com karmic-updates/main Packages
        500 http://security.ubuntu.com karmic-security/main Packages
        100 /var/lib/dpkg/status
     5.2.10.dfsg.1-2ubuntu6 0
        500 http://us.ec2.archive.ubuntu.com karmic/main Packages

Revision history for this message
Ondřej Surý (ondrej) wrote :

Why is that important and should be fixed?

./configure line is different for each SAPI anyway.

Revision history for this message
Dominik (dominik-dokdok) wrote :

php -i and phpinfo() are commenly used to check for the exact configure options passed to PHP ... so basically users expect this output to be there.

Also, the official PHP documentation mentions it. http://ca3.php.net/phpinfo contains in particular

INFO_GENERAL 1 The configuration line, php.ini location, build date, Web Server, System and more.

Revision history for this message
Ondřej Surý (ondrej) wrote :

And what do you need it for?

As I said before, since every SAPI is compiled with different options (modules are built only once), it's output is practically useless.

So what information do you expect to be there and you are missing right now?

It probably an upstream build script failure, which fails to reflect it's being build in separate directory.

Revision history for this message
Dominik (dominik-dokdok) wrote :

I can see several benefits to its presence in the output:
1) educational
2) as a starting point for a new PHP compilation ... basically get that line, modify what you need and you'll be able to recompile PHP

Below a sample output from a CentOS 5 installation:

# php -i
phpinfo()
PHP Version => 5.1.6

System => Linux localhost.localdomain 2.6.18-164.11.1.el5 #1 SMP Wed Jan 20 07:39:04 EST 2010 i686
Build Date => Jan 13 2010 17:05:38
Configure Command => './configure' '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-mime-magic=/usr/share/file/magic.mime' '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' '--with-system-tzdata' '--enable-force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-ncurses=shared' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-ldap-sasl' '--with-mysql=shared,/usr' '--with-mysqli=shared,/usr/lib/mysql/mysql_config' '--enable-dom=shared' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--enable-fastcgi' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-mysql=shared,/usr/lib/mysql/mysql_config' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared,/usr' '--enable-dbase=shared'

Chuck Short (zulcss)
Changed in php5 (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Adam Conrad (adconrad) wrote :

The removal of Configure Command from phpinfo was intentional, see debian/patches/052-phpinfo_no_configure.patch

In short, it led to many (many!) bugs from users claiming that extension X, Y, or Z wasn't built for PHP in Debian/Ubuntu, do to entirely misinterpreting what the string actually means.

If you want to see how PHP is built in Ubuntu, "apt-get source php5", and peruse debian/rules, the ./configure output in phpinfo() is, as the changelog for the patch states, entirely misleading and not terribly informative.

Changed in php5 (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
G9283 (b8732-deactivatedaccount) wrote :

Simply saying "peruse debian/rules" doesn't help much.

It isn't clear at all. The debian/rules file is 761 lines long.

Revision history for this message
Arkadiy Kukarkin (arkadiy) wrote :

I think removing standard, expected information as to not "confuse" users is a bad move; issues with ambiguity in the build options are entirely separate from accurately displaying what they actually are.

Consider this use case: I need to build php with --debug and --disable-zend-memory-manager to use with valgrind, but now I have to *manually* recover the build string from the individual options in order to approximate the configuration I am actually trying to debug.

Revision history for this message
Arkadiy Kukarkin (arkadiy) wrote :

(that should be --enable-debug)

Revision history for this message
Robert Guinness (iamguinness) wrote :

I agree with those commenting in favor of including config info. I tried reading through debian/rules, and it is still unclear to me what the configuration of the compiled php is on my machine. For many users who aren't super familiar with shell scripts, it is difficult to garner this information from this file. I would like to recompile php with some uneeded extensions removed, but it is difficult to know how exactly I should change the configuration command, since I don't know what configuration I'm starting from.

Changed in php5 (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Hugh G. Rection (cmanley-deactivatedaccount) wrote :

This affects whoever needs to detect the state of the interpreter their code is running in, much like ini_get() is used to get ini settings.
In my case, I need to detect if PHP was compiled with --enable-sigchild so that I know how to handle proc_close() calls.

Revision history for this message
Hugh G. Rection (cmanley-deactivatedaccount) wrote :

For now, there is an inconvenient and inefficient workaround:

Execute process 'php-config --configure-options' and parse the output. But that'll probably not work in Windows.

Revision history for this message
Rob Frawley 2nd (robfrawley) wrote :

This causes the Symfony Process component's `sigchild` detection to default to "no". From my inspection of the `debian/rules` file in for latest PHP package, this happens to be the correct behavior for the Process component to take, but this is simply out of dumb luck. What happens when/if that changes in the build routine and suddenly Ubuntu passes `--enable-sigchild`? At that point, the Symfony Process component will be making the wrong assumptions about how to handle this because the required information to detect this is missing.

See the following GitHub issue for when this issue was discovered (it has existed like that now for some time because it just *happened* to work, and the Symfony developers made the *correct* assumption that distributions would not modify the expected and documented behavior of php info:

https://github.com/symfony/symfony/issues/23568#issuecomment-317775279

I'm positive other feature detection uses exist. IMHO, removing standard php_info() output sections for the purpose of lessening your invalid bug count seems like an absolutely horrendous excuse.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.