[TriLUG] Apache2 / PHP / MySQL Help?
jtrilug at indythinker.com
Wed Mar 26 15:32:39 EDT 2008
Brian McCullough wrote:
> Found it. It _is_ compiled in to the php4 binary ( the path to the
> extensions, that is ). That still doesn't explain why the GD extension
> is loading and the MySQL one isn't.
> OK, I tried another "data point." I installed the php4-pgsql extension,
> and it doesn't show up in phpinfo() either. ( This is a _good_ thing,
> because I KNOW that there isn't a PostgreSQL RDBMS in this machine. )
> So it seems that although there is definitely a mysqld running on that
> machine, and it has both a UNIX socket and a TCP one, the PHP mysql
> extension isn't able to communicate with it, and so doesn't announce
> itself in phpinfo().
> Now I've got something to work with.
As long as the client libraries (libmysql?) are installed, it shouldn't
matter whether there is a local instance of MySQL running or not. PHP
should still load the libraries and allow you to attempt a connection to
a remote server. The same should be true of the php4-pgsql extension.
Fortunately, you still are closer to your answer by having installed
php4-pgsql and failing to see it in phpinfo(). Most likely, it means
that either phpinfo() is not a valid test for this or there is something
that's actually broken in your installation. You might want to try a
quick PHP script that exercises the mysql functions, just to see if it's
really missing. If it's actually broken, I think you've probably
narrowed it down to being on the PHP side, not the MySQL side. I don't
think you can fully exclude it, though.
Have you checked in /var/log for anything that might yell about a module
that isn't loading correctly? At this point, I'm thinking that your
binaries are incompatible with each other or something critical is
missing from LD_LIBRARY_PATH. That isn't the sort of thing that should
fail silently, but it might be sticking it in a log somewhere that you
haven't looked yet.
You might want to use the "file" command to make sure all the relevant
executables and shared objects are of the same type (e.g. ELF 32-bit LSB
shared object, Intel 80386, version 1 (SYSV), stripped). If somebody
installed packages for a different architecture, you could run into
mismatches here. You can also use "ldd" and "objdump" to look more
carefully at what's linked to each binary. If this is new to you (or
anyone following along at home), this is one of the better primers I've
found on the topic:
All that is a lot of work, though. Check the logs first. Also, have
you considered uninstalling every trace of Apache, PHP, and MySQL and
then starting with fresh packages? I'm not sure how much work that
Best of luck.
More information about the TriLUG