Php5 and Mysql library Error

I'm posting this for anyone else who has the same problem.

Last night it was working fine. I had compiled php5 using the script at:
http://wiki.dreamhost.com/index.php/Installing_PHP5

This morning I was getting the error:

bin/php: error while loading shared libraries: libmysqlclient.14: cannot open shared object file: No such file or directory

and my sites were just getting an Internal Server Error.

I just deleted the two php binaries.
src/php/php-5.0.4/sapi/cgi/php
src/php/php-5.0.4/sapi/cli/php

Did a make. and then make install. Now everything works fine again.

I have two sites with this problem as well. Just started around 12am, according to my logs (first sign of error was at 12:33am).

I've submitted an emergency site down ticket about it, but no responce yet.

Down on yebra and qbert. Seems to me they've done some moving/removing of MySQL libraries and it's causing some issues. As to what they are doing, i don't know. There is no reason to upgrade the client since their server is still a bit on the outdated side.


*Edit: Ha, and what do you know. They did the MySQL client. I'll try a re-compile of PHP to see if that fixes my problem.Edited by guice on 05/17/05 07:44 AM (server time).

Glad I checked the forum. I had the same thing happen on my three busiest sites - converted to php5 a week ago and humming along beautifully until HOLY COW! this morning, exactly as you describe. Servers fud and bitters.

Um, based on rereading the posts above ... for those of you who actually know what you're doing, am I correct to conclude that my best course is to simply repeat the wiki process just as I did the first time? (And then never sleep again in fear of the sites I'm responsible for crashing brutally on any given night...)

Edited by haggis on 05/17/05 08:02 AM (server time).

My sites died the same way, just before midnight PDT.

I had a copy of PHP 4 lying around, and it has the same problem.

Recompiling PHP fixed the problem.

Being naive (and basically just an 'instruction follower') I would have guessed that all the files etc. necessary were being copied into our own directory structure during that very busy-looking install run by the wiki script, making PHP essentially 'local.' I'd have thought it more or less immune to DH moving things around. Is there a lay persons explanation for what moved and how it affects this local copy of php5? Is it to do with something on the MySQL side more than specifically the PHP bit? I'm just curious. Sorry if the question is too basic or unanswerable :-)

Ah, we upgraded the client libraries because we're prepping for the upgrade to MySQL 4.1 in the next week (it'll happen slowly).

By default PHP compiles so that it uses dynamic linking, so that when it starts is just loads the shared libraries from the system location.

You can force a compile to create a static binary, whereby it actually incorporates the libraries' code into the PHP binary at compile time, so that no matter what happens with the system libraries, PHP should run.

You can pass the --enable-static flag to configure to build a static binary.


nate.

4.1 server? nice!

I have no problems with the uprgade, but a quick advanced noticed would have been nice. :)

Just a quicky "we're upgrading the mysql client on the servers to 4.1.11 tonight at X time" for the servers that were effect (all?).

So .. when will you be upgrading to MySQL 5? :D

Thank you kindly. That makes sense. Maybe a knowledgeable user will document how/where to insert that static option into the installscript in the wiki article. I have to say that wiki article is one of the easiest to follow step-by-step procedures of its kind I've ever encountered.

I'm having the guy who handles the MySQL packages repackage the client libs to include a symlink to the now-missing .so, too.

We'll announce about the upgrade, but nothing's happened yet, so there's nothing yet to announce! The client libs theoretically shouldn't have affected anything...but of course it did!


nate.

In reply to:

---

The client libs theoretically shouldn't have affected anything

---

Famous last words...

If you don't want to recompile PHP, the alternative solution/workaround is to create a symlink called libmysqlclient.14 in php/lib pointing at /usr/lib/libmysqlclient.so.14.

PHP checks its local php/lib directory before looking in /usr/lib.