views:

33

answers:

2

I have enabled PHP 5.3.2 and Apache 2.2.14 on my install of Mac OS X Snow Leopard and have confirmed that I am connecting to it with a call to phpinfo();

On inital startup, it appears that ALL possible extensions are being loaded, as the call to print_r(get_loaded_extensions()) implies:

Array
(
    [0] => Core
    [1] => date
    [2] => ereg
    [3] => libxml
    [4] => openssl
    [5] => pcre
    [6] => sqlite3
    [7] => zlib
    [8] => bcmath
    [9] => bz2
    [10] => calendar
    [11] => ctype
    [12] => curl
    [13] => dom
    [14] => hash
    [15] => fileinfo
    [16] => filter
    [17] => ftp
    [18] => gd
    [19] => session
    [20] => iconv
    [21] => json
    [22] => ldap
    [23] => mbstring
    [24] => standard
    [25] => mysqlnd
    [26] => SPL
    [27] => odbc
    [28] => mysqli
    [29] => PDO
    [30] => pdo_mysql
    [31] => pdo_sqlite
    [32] => Phar
    [33] => posix
    [34] => Reflection
    [35] => mysql
    [36] => shmop
    [37] => SimpleXML
    [38] => snmp
    [39] => soap
    [40] => sockets
    [41] => SQLite
    [42] => exif
    [43] => sysvmsg
    [44] => sysvsem
    [45] => sysvshm
    [46] => tokenizer
    [47] => xml
    [48] => xmlreader
    [49] => xmlrpc
    [50] => xmlwriter
    [51] => xsl
    [52] => zip
    [53] => apache2handler
)

When I edited the php.ini.default and created the /private/etc/php.ini, I commented out all of the extensions available to prevent loading (for now I was just trying to get a baseline). Even after restarting Apache with the new php.ini info, all of the extensions are still loading. My guess is that since NO extensions are being explicitly loaded, PHP is reacting the same way it would if I had no php.ini.

What perplexes me is that when I attempt to find the library files associated with the "loaded" extensions, I can find NONE! I have searched my entire hard drive as root user looking for any trace of the *.so library files and have found none (ex: call to find / -name 'mysql' returns no files that are php extension libraries). And there is only one *.so file in the /usr/lib/php/extensions/no-debug-non-zts-20090626 directory listed as the extension_dir for php. Why would php say that is is successfully loading them then?

Here is the gd extension result from phpinfo() as an example: http://www.concentricsoft.com/downloads/phpinfo_sc1.jpg

I confirmed that the changes I made to the php.ini file took effect: I set the error_log= to a file and am able to write to it using a call to error_log($string, 0);

I have not tried to run code yet that would attempt to use any of the extensions that php says are loaded, so I guess that is my next move, but I just wanted to see if anyone else out there solved this issue and if so how.

+1  A: 

Many PHP extensions can be built statically, as part of the php executable instead of as shared object files.

You can even build PECL extensions statically.

Bill Karwin
A: 

I see, so if it is built into the php executable then of course it will load no matter what is specified in the php.ini...makes sense. Thanks for the help. I just wanted to make sure I wasn't going insane.

Jim Rosengarth