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
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
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.
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:
"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."
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)
/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:
http://bugs.php.net/bug.php?id=42464
I would love to know what I could have done better.
-J
[Index of Archives]
[PHP Users]
[PHP Home]
[PHP on Windows]
[Kernel Newbies]
[PHP Classes]
[Postgresql]
[PHP Books]
[PHP Databases]
[PHP SOAP]
