PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0,

Thanks to the error up and below(with some referrer from China) I have my WordPress website once a day or 2 days down - 505 internal server error. To make my website run again I always need to delete .htaccess file .
Can anybody help me to explain what is wrong , has my website been hacked or what those errors means? I'm sure that foreign URLS is something that in my errors cant be :

[Sun May 23 03:40:59 2010] [error] [client 213.5.70.184] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0, referer: http://forum.vipearn.com/thread-10523-1-1.html

Can anybody help me to explain how to eliminate this problem? Unfortunately im not PHP - Apache expert at all ,
I would be very happy if anybody can respond , Daniel

1) ./configure couldn't find my zlib dir, so I had to edit .setup.sh to be:

./configure --prefix=/usr --with-pdo-mysql=/usr/local/mysql --with-zlib-dir=/usr/lib/

2) The original .setup.sh wants to build every architecture, and this seemed to be failing with everything except i386. But you already established that you only need the i386 version. So I modified the script to be:

CFLAGS='-O3 -fno-common -arch i386' \

3/ I had to tell php.ini where the .so file was:

extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20060613/"

4/ The trick of creating /Library/LaunchDaemons/org.apache.httpd.plist was fine for a reboot of the computer, but didn't work when you bounced Apache through System Preferences. In the later case Apache still came up in x64 mode. I had to edit /System/Library/LaunchDaemons/org.apache.httpd.plist to get the system to always come up in i386 mode

Thanks for the comments! A lot of this is no longer necessary thanks to Snow Leopard, and I still think recompiling the stock PHP is a Bad Idea... In general, I do my best to avoid changing anything that Apple considers to be core system software, eg. /System. In general, if the PHP needs configuring properly, I think it's worth doing in a separate tree, like MacPorts does.

...but it's all about knowing when to bend the rules, too :)

To elaborate on the phpinfo() step, at the Terminal, type:

php -i | grep 'Configure Command'

That should return the command Apple used to configure the PHP build. After tweaking and running that line, it's just a make && sudo make install.

Also these instructions works on 10.6 (MySQL build only, PDO module build is no longer required) with some adjustments: remove -arch ppcXXX and replace 10.5 with 10.6.

However you will probably want to add pdo_mysql.default_socket=/var/mysql/mysql.sock in your php.ini. The default Apple installation has not configured the module correctly.

@ stephenrs, About the zlib error actually if you checkout config.log you will find that is not able to use some library due to a different architecture (it's not the very last line but it's some line before). You are probably compiling a 32 bit extension and trying to use a 64 bit library.

Bye

Using your (very nice, btw) instructions, on the ./configure line, I'm getting the error:

"configure: error: Try adding --with-zlib-dir=. Please check config.log for more information."

I come from the days before RPM's and yum, so I'm no stranger to compiling things from src and dealing with dependencies...I just would never have guessed that my Mac would be the thing that blasted me back 10 years to having to pick through config.log files to hammer a silly little .so into submission. :(

If anyone has any advice on what problem is indicated by that zlib error, I would be very grateful...off to dependency purgatory I go...

What a nightmare!

The problem is that Apple's PHP is compiled with mysql/mysqli support built-in using the 5.0.67 MySQL client library. I'm not sure if it's statically linked or not.

Anyway, I can't see a way to compile PDO_MYSQL as a shared extension but statically linking in the 5.1 client library. So, while it compiles against the 5.1 library, it seems to run with the 5.0.67 library. This is verified using phpinfo().

As a result, queries _seem_ to work, but don't always return the correct results.

While I usually try to stick with the stock Leopard php module, I'm admitting defeat and compiling a new one. Rather than using one of the standard PHP bundles, I'm compiling a fresh one using Apple's configuration parameters (also from phpinfo()), but removing the mysql and mysqli extensions.

I'm then going to compile those as dynamic extensions THE WAY APPLE SHOULD HAVE IN THE FIRST PLACE!

Apple, if you're listening/googling, if you're going to include a PHP, please just include a very bare-bones install without compiling in any extensions that can be dl'ed instead! I understand why the stock PHP doesn't include every extension under the sun (good plan), but there's no reason why it needs to include some extensions that limit future expandability.

Okay, the PDO ext needs to be static on Darwin, but the mysql, mysqli, pdo_sqlite extensions would work perfectly well if dl'ed rather than statically linked, and it would make upgrading MUCH easier.

-- I used your guide with some modifications to come up with a full 64bit python web stack

see http://blog.captnswing.net/2009/04/19/python-mod_wsgi-64bit-mac-os-x-105/

I just hope upcoming macosx updates won't screw up my setup!

The ones provided result in this error:

"configure: error: C compiler cannot create executables"

Anyone come across this problem?

To be honest, since I found out how to flip Apache into 32-bit mode (as shown in the comments above), I just use the standard 32-bit binary distributions of MySQL rather than compiling my own.

cirpo

However, you may wish to either share a var or data directory between all mysql versions, or a separate var for each build. It depends on taste and also the particular needs of your environment.

If you want to use /var, then a subdirectory should be made, eg. /var/db/mysql and that path compiled in.

Thanks

ln -s var data

instead of:

ln -s /var data

cheers

I set up a couple of command line aliases to twiddle ARCHFLAGS for different compilation modes, but ended up going with the launchd method above.

However, I have noticed that the /Library/LaunchDaemons override doesn't seem to be working now. Instead I've had to end up changing /System/Library/LaunchDaemons/org.apache.httpd.plist instead. I really don't like changing anything in /System though, but /Library didn't seem to be taking precendence (which I think is wrong).

Ended up rolling my own apache though.

Btw, think the arch stuff can be set globally with just ARCHFLAGS='-arch x86_64 '


MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS='-O3 -fno-common -arch x86_64' LDFLAGS='-O3 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch x86_64' \
./configure --prefix=/usr --with-pdo-mysql=/usr/local/mysql


…basically, I removed the 32-bit Intel directives, the PowerPC directives, and also made sure that my MySQL path was correct. For example, a port install of MySQL, and including PowerPC and Intel 32 bit versions might be:


MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' LDFLAGS='-O3 -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
./configure --prefix=/usr --with-pdo-mysql=/opt/local/lib/mysql5/mysql


Hope this helps!

[Mon Sep 15 01:20:19 2008] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so' - (null) in Unknown on line 0
[Mon Sep 15 01:20:19 2008] [notice] Digest: generating secret for digest authentication ...
[Mon Sep 15 01:20:19 2008] [notice] Digest: done
[Mon Sep 15 01:20:19 2008] [notice] Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.7l DAV/2 PHP/5.2.6 configured -- resuming normal operations

Any idea/advice would be greatly appreciate it.

Thank you for your time.

Anyway, I'm convinced the 32-bit mode approach in the comments above is a far better way than I suggested in the main body of the post.

- Install mysql (32 bit) from the package on mysql web site
- Compile & install the pdo_mysql extension
- Force apache to run in 32 bit following your advice

It works great; now having PDO_MYSQL both in Apache and command line PHP.

Since the original Intel Macs used 32-bit Core processors, rather than the 32/64-bit Core 2, the version of Apache must be capable of running 32-bit, so there shouldn't be anything in Mac OS X that needs 64-bit Apache... right?

I can think of two ways of forcing this: either modifying httpd by using lipo to remove all but the i386 executable, or by overriding /System/Library/LaunchDaemons/org.apache.httpd.plist

Rather than modifying the file in /System/Library which is rarely a good idea, just override it by copying /System/Library/LaunchDaemons/org.apache.httpd.plist to /Library/LaunchDaemons/org.apache.httpd.plist and change:

                <string>/usr/sbin/httpd</string>
                <string>-D</string>
                <string>FOREGROUND</string>

to

                <string>arch</string>
                <string>-i386</string>
                <string>/usr/sbin/httpd</string>
                <string>-D</string>
                <string>FOREGROUND</string>

Activate it by rebooting or:

sudo launchctl unload /System/Library/LaunchDaemons/org.apache.httpd.plist
sudo launchctl load /Library/LaunchDaemons/org.apache.httpd.plist

Anyway, I don't know if this approach will work, but you should be able to operate everything in 32-bit mode, which should be a lot simpler. Use the standard 32-bit PDO, MySQL and so forth. If you actually need a 64-bit Apache, then you're on your own... the approach in the article above might be the way to go.

dyld: NSLinkModule() error
dyld: Symbol not found: _core_globals
  Referenced from: /usr/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so
  Expected in: dynamic lookup

I suspect that this is because the php command is compiled 32-bit only. I'm not sure of the "proper" way to fix this, but I got around it by using a different php.ini file for Apache.

First, delete the /etc/php.ini file (or at least, remove the offending extension lines)

Then, create /etc/apache2/php.ini with the extension lines.

Then, add:

        PHPIniDir /etc/apache2

to the middle of /etc/apache2/other/php5.conf