I've looked everwhere for the answer to this problem. Lots of people
are having the same problem and nobody has mentioned a correct and
proper fix for it.

namely:

   bash-2.03# Syntax error on line 236 of /etc/httpd/httpd.conf:
   Cannot load /usr/lib/apache/libphp4.so into server: ld.so.1: /usr/sbin/httpd: 
fatal: libmysqlclient.so.10: open failed: No such file or directory

How, exactly, do you compile PHP so that the proper -R, -L, -l flags (or anything else
needed) is done correctly so that php correctly loads 
/usr/lib/mysql/libmysqlclient.so.10
instead of onyl defaulting to /usr/lib/libmysqlclient.so.10??

Possible solutions (and why they aren't correct)
   1) put
        LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/mysql
        export LD_LIRBRARY_PATH
      into whatever script you use to launch the httpd that includes mod_php.
      (I use /etc/rc2.d/S99httpd)

   This solution is undesirable for two reasons:
     Most importantly you are forcing to PHP to screw around with a script or
     file that belongs to some other package. Having PHP fiddle with a file it
     doesn't own and isn't directly related to should be a no-no.

     Second if you have to go and put LD_LIBRARY_PATH files all over the place
     then we don't really need a dynamic linker at all really. As I see it the
     whole job of ld is to figure out where libraries are and link to them without
     having to be told all the time how to do its job. This is backed up by the
     fact that I don't have to use LD_LIBRARY_PATH statements for *anything* else
     this implies that PHP is doing something non-standard and should be corrected.

   2) Put a link from /usr/lib/libmysqlclient.so.10 to 
/usr/lib/mysql/libmysqlclient.so.10

   This solution is wrong again for a couple of reasons:
     The same reason as the other solution. PHP is imposing conditions about file
     directory layout for files which it does not own and are not directly related to.
     If there needs to be link such as this then mysql should determine this and
     make and maintain such a link.

     But more importantly: If you need to put all the darn libraries is /usr/lib
     then you're an administration idiot. You're a double idiot if you put files
     in nice subdirectories AND add links for each one in /usr/lib. This would
     imply that you can't put libraries elsewhere and you would wind up with a\
     flat file hiearachy that would resemble your mothers C:\ drive on a Windows
     box... Just full of junk and totally unmaintainables. Certainly not what I
     want to see happen with my /usr/lib. Yes, Yes, a single link to fix a single
     problem... no so bad. But there *must* be a better way since only PHP is
     causing me this headache so on philosophical level this solution should be
     avoided in favor of fixing php.

Now the correct solution (which I cannot figure out how to do correctly)
   3) compile php so that it looks for or otherwise hints to ld as to the absolute path
      that is needed to find the libraries it needs.

      If PHP can find libmysqlclient.so (which I would guess it must in order to
      be built otherwise configure would bomb out.) then it should be able to
      hint to ld during runtime as to where it found the library.

      With this solution PHP only screws with itself and not with the files installed
      by another package. This is good. This is the way it should be. I'ld love
      to hear some cogent arguments that contradict this.

      And the mysql Solaris.html page I found says that you can compile the
      mysql client (in this case I think "mysql client" refers to the PHP client
      being compiled with mysql support and not mysql itself.) with
      -Wl,r /usr/lib/mysql (which isn't correct because -R (not -r) is the
      absolute reference switch for ld according to the man page.

      anyhow...

How, exactly, do you compile PHP so that the proper -R, -L, -l flags (or anything else
needed) is done correctly so that php correctly loads 
/usr/lib/mysql/libmysqlclient.so.10
instead of only defaulting to /usr/lib/libmysqlclient.so.10??

I'm compiling PHP with this:

EXTRA_LDFLAGS="-R /usr/lib/mysql" ./configure  \
                --with-layout=GNU \
                --prefix=/usr \
                --libexecdir=/usr/lib/php \
                --sysconfdir=/etc/php \
                --datadir=/usr/share/php \
                --sharedstatedir=/var/php \
                --localstatedir=/var/php \
                --mandir=/usr/share/man \
                --with-apxs \
                --enable-safe-mode \
                --with-openssl \
                --enable-magic-quotes \
                --with-zlib \
                --enable-dba=shared \
                --with-regexp=php \
                --with-mysql=/usr \
                --enable-sockets \
                --enable-sysvsem \
                --enable-sysvshm \
                --enable-wddx \
                --disable-debug \
                --with-config-file-path=/etc/php \
                --with-exec-dir=/usr/lib/php \
                --enable-pic \
                --with-ttf \
                --enable-inline-optimization

I have also tried:
EXTRA_LDFLAGS="R /usr/lib/mysql/libmysqlclient.so.10" ./configure ...
EXTRA_LDFLAGS="-Wl,r /usr/lib/mysql/libmysqlclient.so.10 ./configure...
EXTRA_LDFLAGS="-Wl,R /usr/lib/mysql/libmysqlclient.so.10 ./configure...
I have also done the same with /usr/lib/mysql substituted for
/usr/lib/mysql/libmysqlclient.so.10 and I have also tried all of the
above with EXTRA_CFLAGS=...
None of these worked.

I'm pretty much at the point of telling my web people to take a hike. I don't
want to install PHP on over a hundred machines where it is going to cause me
more maintenance headaches because it screws with the packages I've already
installed which it shouldn't.

come on, there must be a way of compiling php to get its linking right.
Please, for the second time, help me figure this out.

Thank you,

Jeff Wiegley


-- 
PHP Install Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to