Re: Trying to load MySQL libraries from wrong location, configure failing

[BuildSmart <buildsmart@xxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 2, 2007, at 06:55:54, Juan A. Pons wrote:

> On Sep 1, 2007, at 10:57 PM, BuildSmart wrote:
> >
>
> > But the problem only exists when you use the mysql.org binaries so  
> > that should tell you something.
> Apparently does not, since a second bug was filed after mine was  
> classified as Bogus. I have also tried a completely clean install  
> TWICE to confirm this... NEW OS, NEW MySQL install from binaries,  
> NEW Apache, NEW PHP and the problem still persists, I have been  
> able to reproduce this more than 8 times ALL on OSX 10.4.10

The problem arises when using the builds from mysql.org, I have seen  
no issues with any other builds despite the location of the libraries  
so reporting an issue with libraries being in /usr/local/mysql/lib  
instead of /usr/local/mysql/lib/mysql makes it bogus.

> > OK so you don't need me to fix it, how about checking the contents  
> > of the php-5.2.4/ext/mysql/mysql.config.m4 file, maybe it's faulty  
> > and this is what needs to be brought to their attention.
> I have checked the contents of config.m4 and there do not seem to  
> be references there,
>
> But if you read my original bug report that can be found at:
> http://bugs.php.net/bug.php?id=42464
>
> You can see that no matter what you do the configure script will  
> insist on using /usr/local/mysql/lib/mysql references

Again, this only occurs if you use the mysql.org builds.

> > You cannot use the OSX binaries in other environments so claiming  
> > you can link against this installation in another environment like  
> > RH9 or something else is false.
> When I said environments, I did not mean Operating environments I  
> mean programming environments, this is why I mentioned Perl,  
> Python, MySQL
>
> > Having success with programs like ruby, python, perl only means  
> > that they are more tolerant of the faulty installation, maybe this  
> > approach is what needs to be brought to the PHP teams attention.
> Correct and THIS IS EXACTLY what I am trying to do, but it seems  
> that either people are not interested in getting PHP working right  
> out of the box with the most popular Database system, on the  
> fastest growing OS platform. I am just baffled.

It does work properly out of the box, the fact that you are using a  
fuqed up binary install of MySQL doesn't mean that the problem is  
with PHP.

> > As I said, I don't believe you don't have a problem, I'm  
> > interested in a solution to the problem you are having so if you  
> > really wanna help then start by providing some info on the problem  
> > when your queried about it.
> Incorrect, if you look at your first communication, you did not ask  
> for any information, and clearly had not read the bug reports, all  
> you told me that the bug was in fact bogus, because my MySQL  
> installation must be faulty, quoting you:

I'm talking about now....

> "The only time I see the symlink trick and people having finding  
> and binding issues in OSX is that mysql isn't built/installed  
> properly in the first place."
>
> You then proceeded to say:
>
> "This means the bug you are trying to report is in fact bogus, I  
> have MySQL-5.0.24 installed in /usr/local/mysql/ and I don't have  
> any finding or binding issues."

I have an install of 5.0.24 with libraries in /usr/local/mysql/lib,  
there are no issues finding or linking to these libraries so your  
claim that the PHP script is at fault is bogus if you cannot show why  
it fails and your only claim is that the libraries are in /usr/local/ 
mysql/lib which is where mine are located.

> And yes this works fine if you compile your own MySQL and or if you  
> do not rebuild the configure script, both of which I detailed in my  
> original bug report.
>
> If you follow the installation steps in my original bug report you  
> wil see that the build fails as it has for me (and now apparently  
> others) many times.
>
> > > As I said, I don't need to you fix the issue for me as i already  
> > > have done that, I am just trying to contribute and file what seem  
> > > to be bugs, but the way that we are treated here makes you wonder  
> > > why we even try.
> >
> > Adding the symlinks is not a proper fix, if you claim it is then  
> > perhaps a line can be added to the configure script that upon  
> > error informs you that you might need to create the symlink  
> > because you're using the mysql.org binaries.
> I agree that adding the symlinks is not the right thing to do, this  
> is what I filed the bug in the fist place.
>
> > Please send me the output of "otool -L /usr/local/mysql/lib/ 
> > libmysqlclient.dylib", this might provide the answers needed.
>
> BTW this is the first time anyone has asked for any diagnostic  
> information... Here is the output you requested:
>
> $ otool -L /usr/local/mysql/lib/libmysqlclient.dylib
> /usr/local/mysql/lib/libmysqlclient.dylib:

_____________________________________


>         /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib  
> (compatibility version 16.0.0, current version 16.0.0)

You just found your problem and proven it's not a PHP bug!!!!!

Your libraries are using a runtime path of /usr/local/mysql/lib/mysql  
but a physical path of /usr/local/mysql/lib and the failure occurs  
when it tests functions in the library.

You have two choices here, either use install_name_tool to fix the  
libraries or complain to mysql.org that they are providing faulty  
binaries (or both).

_____________________________________


>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current version 88.1.5)
>
> As far as I am concerned the problem may very well be with the  
> MySQL packages, but guess what these are the packages that  
> mysql.com/org is distributing, if we want PHP to work with MySQL as  
> it's being distributed, then a fix is in order, if not we call bury  
> our heads in the sand and do nothing about it which is what it  
> seems like the PHP team is doing.
>
>
> > I'm not part of PHP development team, I am an end user but also an  
> > ex-apple programmer, I have shown that the PHP configure script  
> > does search in both path formats but you continue to claim it is a  
> > PHP bug but cannot show anything more than the symptom so to  
> > identify the issue a little preliminary work needs to occur,  
> > filing that weak bug report will result in the same conclusion as  
> > the previous one unless you can substantiate the claim to some  
> > degree.
>
> Can you tell me what was "weak" about my bug report that can be  
> found here:

It's weak because it gives symptoms of a problem, provides some  
detail but shows the reason for failure is related to the libraries  
being in /usr/local/mysql/lib rather than /usr/local/mysql/lib/mysql  
so if it can be shown that having libraries in /usr/local/mysql/lib  
works then the bug report is bogus and this can be shown.

> http://bugs.php.net/bug.php?id=42464
>
> I would love to know what I could have done better.
>
> -J

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFG2rML0hzWbkf0eKgRAoMYAKDAk9KHz94eehKAU6N9NBU+ra+1+QCgiKeC
4C5TpCTQEfcH5ltxkUgiaPo=
=cBZ5
-----END PGP SIGNATURE-----