Re: [PHP4BETA] [REF BUG: 4234] Re: [PHP4BETA] php4 and mysql

Just got back and got to this mail. I've just submitted a bug report, 4277. I agree, the LD_RUN_PATH env var is a workaround only. I think it's better than having to have httpd running with LD_LIBRARY_PATH set though, but feels like a kludge, and a lot of people may not think to try it.

                -glenn

At 11:13 AM 4/26/00 , Joey wrote:

Glenn:

        It seems you are not the only one having the problem, nor does it

seem limited to the Solaris platform. See http://bugs.php.net/?id=4234. Therefore, I am adding the PHP4 list back into the mix. I know Sascha is really busy right now, mainly bcz I keep bugging him, but I'm thinking he is probably the one who knows the best answer to the problem.

        In a nutshell, the libmysqlclient.so's directory is not getting

added when compiling, at a minimum, php4 as a dso using an already built version of mysql.

        Yes, the LD_* environment vars will fix this, but it is not, IMHO,

the /RIGHT/ way to do it. LD_LIBRARY_PATH and friends are pretty commonly looked at as a security hole, much like having "." in your PATH. But I'm sure not everyone will agree.

        If you could open another bug, mark it as Dynamic reloading

related, I will add what I know to the end, and we'll see if we can't figure out what is going on. Maybe it's time I understood the relationship between ld, libtool, and gcc better??

        --Joey Smith

Please forgive the long sig: *** Notice To Bulk Emailers: Attention! Pursuant to US Code, Title 47, Chapter 5, Subchapter II, 227, any & all unsolicited commercial e-mail sent to this address is subject to a download and archival fee in the amount of the $1500 US and copies will be forwarded to domain administrators. Emailing denotes acceptance of said terms! On Tue, 25 Apr 2000, Glenn Little wrote: Well, it turns out that if I setenv LD_RUN_PATH to be the path to the mysqlclient library, then do the config/make/install, the library gets that built into its search path, so at runtime that directory gets searched, and all is well. (By the way, it appears that LD_LIBRARY_PATH would work if it was set in the httpd's running environment. I don't really want to rely on that though). However, this doesn't seem right, does it? I sort of thought the install was supposed to be a little more bullet-proof than that. Seems like a kludgy solution, and not one that's friendly to your average sysadmin. Maybe I'm the only one having this problem, but I just don't have enough know-how to figure out how else that path is supposed to get in there. Given my "make" output, I'd think it would be there by virtue of the -L and -R flags (as you mentioned), but I don't understand the road to libphp4.so... something happens with libtool, something happens with apxs, and in the end after a "make install", you've got a new libphp4.so. Voila :-) Does it sound like a bug, or just a "that's the way it is"? I thought I saw some other messages go by while I was working on my previous problem that said things about making some env settings. Hmmm.... So, I'm not sure if I should bother the list with this now or not. Or clutter the bug reports site (seems like the more lame non-bugs that get reported, the less effective that site will really be). On the other hand, if this is going to catch other solaris installers... Also, you mentioned linking with the shipped mysql routines? Is that documented somewhere? Is that the preferred way to go instead of using --with-mysql=<my-own-install>?

              -glenn

From joey@samaritan.com Tue Apr 25 14:15:53 2000 Date: Tue, 25 Apr 2000 15:19:29 -0600 (MDT) From: Joey <joey@samaritan.com> To: Glenn Little <little@cs.ucsd.edu> Subject: Re: [PHP4BETA] php4 and mysql MIME-Version: 1.0 X-Status: X-Keywords: X-UID: 48461

I'm not sure if you meant httpd, or libphp4.so, so I'll include both. It looks to me like libphp4.so is either not getting told the right path to find libmysqlclient at dynamic load time, or, actually... shouldn't it just statically link with libmysqlclient? I understand why libphp is a dynamic library, but why is it in turn built with a further dynamic dependency?

    Sorry, human error. You were right, I needed libphp4.so.
    It is building against the dynamic libraries bcz that is what
    php links against for mysql support. I do not know if there is
    any way to build libphp4.so as a static lib. to be loaded or not.
    More of a question for Sascha, or one of the other guys.

What is the mechanism for building the right dynamic lib search path into libphp4.so?

    Again, I am kind of unclear myself on this, but I am mystified
    as to why you ld /ONLY/ looks in /usr/lib. Don't you have a
    /usr/local/lib? Why is it not being searched? There is a -R
    flag that should be getting passed to your linker at compile time
    that tells it where to look for loading libs. /web/mysql should be
    getting into that list. Looking through the man page for ld.so.1,
    I found the following:

      The runtime linker uses a prescribed search path for  locat-
      ing  the  dynamic  dependencies  of  an object.  The default
      search paths are the runpath recorded in  the  object,  fol-
      lowed  by  /usr/lib.   The  runpath  is  specified  when the
      dynamic object is constructed using the -R option to  ld(1).
      LD_LIBRARY_PATH  can  be  used to indicate directories to be
      searched before the default directories.

    I'm pretty sure I saw that on the tail end of your make output,
    so why it isn't working is beyond me...I'd reccomend putting a
    short decription of the problem together and logging it as a bug,
    so that someone like Sascha can have a look at it.

    Another thing you may want to try is using the built-in mysql libs
    that are now shipped with PHP4. I imagine that should work a bit
    better at the linking point, as there has been a lot of
    collaboration between PHP and MySQL to get that working. But there
    are some problems (here and there) with the compile.

I imagine that putting libmysqlclient in /usr/lib would work, but I'm hesitant to do so since the solaris admin people here want to keep /usr/lib standard and pristine. I'd have to ask them to update tripwire, and rdist database, etc to move it. If you believe it's an important diagnostic to try, I can do it. I'd just prefer not.

    That's fine...wasn't sure if you guys were running any of that
    stuff. I can certainly understand not wanting to mess with that.
    Putting libmysqlclient in /usr/lib definitely /SHOULD/ work, but
    I think in your case it classifies as a "last resort".

-- PHP 4.0 Beta Mailing List <http://www.php.net/version4/> To unsubscribe, e-mail: php4beta-unsubscribe@lists.php.net For additional commands, e-mail: php4beta-help@lists.php.net To contact the list administrators, e-mail: php4beta-admin@lists.php.net