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

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". > > >