[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-install
Subject:    Re: [PHP-INSTALL] Trying to load MySQL libraries from wrong location, configure failing
From:       BuildSmart <buildsmart () daleenterprise ! com>
Date:       2007-09-03 0:47:06
Message-ID: 9930A3F8-D90B-4529-9AC8-EC21AC678494 () daleenterprise ! com
[Download RAW message or body]

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


On Sep 2, 2007, at 19:19:34, Geoffrey Sneddon wrote:

>
> On 2 Sep 2007, at 23:42, Juan A. Pons wrote:
>
>> See my previous email, as yes other programming environments work  
>> perfectly well with this MySQL installation and as a matter of  
>> fact so does PHP when using the packaged configure script. As my  
>> bug reported, the problem occurs only after rebuilding the  
>> configure script. And this is without the symlinks.
>
> My bug reported that is happened with the stock configure script.

Using the pre-packaged binaries from mysql.com/mysql.org I wasn't  
able to make it work with an unmodified or a modified configure  
script without fixing the runtime paths or adding the directory and  
moving the libraries either (I tried both methods for sanity  
purposes, not mine, the PHP build scripts).

The symlink is an easy to implement solution but is not the correct  
one, moving the libraries to /usr/local/mysql/lib/mysql or fixing the  
faulty runtime paths is the proper solution.

It's also best to ensure that the header files are also located in  
same path convention, examples, /usr/local/mysql/lib/mysql & /usr/ 
local/mysql/include/mysql or /usr/local/mysql/lib & /usr/local/mysql/ 
include so that the same path convention is used for both library and  
headers files because some scripts don't test the paths separately.

I've recently complained on the mysql.com forum (which was removed)  
about the faulty runtime paths and the private response was "the  
provided binaries are solely for the purpose/use of the mysql server  
software and the libraries are provided as a courtesy for those who  
wish to pursue development with the client libraries" but no one  
willing to go on record and make any kind of public formal statement  
to this or any other fact.

I've left another post that outlines the issue and suggest the easy  
solution so they don't feel like idiots cause I know at times I'm a  
little harsh in my responses.

To me, this looks like they just got caught offering a faulty  
distribution and rather than publicly say OK we fuqed up and fix it  
they decide to privately say no we provide it that way and it's up to  
the developer to substantiate/validate the libraries and have no  
intentions of offering a fixed version at this time.

Oh yeah, it was also recommended that I install from source rather  
that use the binary distribution.

I will be the first to admit, no one likes to be told their shit  
stinks, however if you can show why it stinks it's easier to accept  
and do something about it but if you just say it stinks and I spray  
perfume on it, it's harder to accept as a real issue since I've  
already taken steps to correct it, the same holds true for PHP and  
the PHP-DEV group the bigger issue in a bug report is showing the  
validity of the bug which people seem to miss.

>
> -g

- -- Dale

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

iD8DBQFG21mK0hzWbkf0eKgRAiyNAJ9a0Pmf6AKJ1o4lMAQ4uRxNlBc0rwCfanwJ
N59z/0O4j1C+1cNLDxMX7uk=
=qRY/
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]