Today I discovered that you are unable to compile the current stable PHP version 5.3.4 with yesterday’s MySQL 5.5.8 GA release. I was able to download the current MySQL 5.1.54 and compile without issue.
You can find all the gory details in Bug #58987 however I was able to edit a number of MySQL include file to get a build. Does this mean it’s a MySQL packaging problem or a PHP problem I don’t know, but I would hope that Oracle in the testing phase of a GA release test this against popular programming languages starting with the LAMP stack to ensure compatibility such as what I uncovered.
Just compiled with 5.3.4, MySQL installed from sources. FreeBSD 8.1.
configuration string: “./configure –prefix=/usr/local/php54 –disable-all –enable-fpm –enable-sockets –with-zlib –with-gd –with-mysqli=mysqlnd –with-curl –with-mcrypt –enable-json –without-apache –disable-cli –enable-embedded-mysqli –enable-session –with-iconv -enable-xmlwriter –enable-simplexml –enable-libxml –enable-mbstring –with-mysql=/usr/local/mysql –with-jpeg-dir=/usr/local/lib/ –with-png-dir=/usr/local/lib/ –enable-xmlreader –enable-pdo –enable-xml –enable-bcmath –enable-ctype”
Try to move out from CentOS, we’ve been having a lot of troubles with performance. High IO usage with MySQL and EXT3.
Why not use the mysqlnd driver?
–with-mysql=mysqlnd –with-mysqli=mysqlnd –with-pdo-mysql=mysqlnd
Justin,
because Ronald was in desperate search for a sound headline.
@Ulf, that has nothing to do with it. To promote MySQL 5.5.8 which as I’ve already blogged about I want to do actively, if I then recommend this to client, and the platform is CentOS 5.5 and they want me to configure a development server for existing code that uses mysqli() I’d be most happy if it worked.
It didn’t.
The headline is concise, because too many people write fluff headlines.
The current MySQL GA and stable PHP don’t get along, at least with mysqli(). My only oversight was perhaps not considering that an applicable keyword.
I discovered the issue, I tested it a second time, I verified my environment with a different MySQL version, I searched for any information via google and MySQL bugs to see if this was mentioned, I didn’t find anything, and I then reported a problem. That’s what people should do with Open Source. Too many people don’t even take the time to do this.
I also had an issue compiling libmemcached with particular error (not seen via my Ubuntu instances), however I found via google a workaround, I confirmed that work and left a note saying thanks. I don’t do desperate stuff, I’ve shared my experience for tbe benefit of others.
Ronald,
PHP 5.3.4 and MySQL 5.5.8 do work! No issues, if using recommended defaults: mysqlnd.
Citing you:
“[17 Dec 17:50] Ronald Bradford
A workaround that requires no code changes is:
–with-mysql=mysqlnd –with-mysqli=mysqlnd –with-pdo-mysql=mysqlnd”,
http://bugs.mysql.com/bug.php?id=58987
Your headline headline does not tell full story. As a statement without context it is even wrong. Headlines often appear without context on blog aggregators. I would not raise my voice, if you used a headline telling the full story.
The full story is:
PHP 5.3.4 and MySQL 5.5.8 – works if using mysqlnd (default and recommended)
PHP 5.3.4 and MySQL 5.5.8 – does not work if using libmysql (your choice)
If your headline would be “MySQL 5.5.8 GA and PHP 5.3.4 using libmysql fails”, I would not have said anything. You should know the importance of the little addition “using libmysql” to well.
In your reply to my nasty, unfair and short blog comment you say:
“The current MySQL GA and stable PHP don’t get along, at least with mysqli().”
The full story is:
PHP 5.3.4 and MySQL 5.5.8 – works if using mysqlnd (default and recommended)
– ext/mysql works
– ext/mysqli works
– PDO_MySQL works
(as you have confirmed yourself at http://bugs.mysql.com/bug.php?id=58987 (see above))
PHP 5.3.4 and MySQL 5.5.8 – does *not work if using libmysql* (your choice)
– likely no extension works
– http://bugs.mysql.com/bug.php?id=58987
– likely regression, http://bugs.mysql.com/bug.php?id=51925
Look, I’m not trying to hide bug #58987. It exists. It stinks. It is ashaming. No excuse for such regression.
However, what makes me argue is that you put my baby mysqlnd into bad light with your bold headline.
I have no idea why you use libmysql[client] (AKA MySQL Client Library). The MySQL native driver for PHP (mysqlnd) has been developed to remove the need of having the MySQL Client Library on the build host. Its easier to compile PHP using the mysqlnd library than using the MySQL Client Library:
-with-mysql=mysqlnd
-with-mysqli=mysqlnd
-with-pdo-mysql=mysql
If you think mysqlnd is not worth using, please kick our asses until it flies. I call mysqlnd stable and production ready.
Mysqlnd is there to get rid of issues like http://bugs.mysql.com/bug.php?id=58987 . If there’s any issue with mysqlnd on any platform, php.net folks can fix it without having to wait for MySQL server releases or without having to consult a MySQL guy. With that libmysql issue you now wait for both the fix and a server maintenance release – enjoy.
Mysqlnd is PHP license. No GPL + FLOSS discussions, no commercial license, no contributor license agreement, no crazy bug systems, no pain. Think back only a few years and the outdated libmysql used by php.net for Windows builds. Problem gone thanks to mysqlnd. Still some argues with Pierre from time to time but nothing that stops Pierre inviting me to his place. And the number of outcries from Pierre on mysqlnd goes down and down.
I do not know of anything better we could have done for the PHP project and [L|W|S]AMP.
Use mysqlnd and become happy.
Try the fancy mysqlnd plugin API. It takes 10 lines of PHP to monitor all statements run through any of the PHP mysql APIs (ext/mysql, ext/mysqli, PDO_MYSQL). There’s a neat ini setting for returning INT columns as integers and not as string although using the text protocol (= if not using prepared statements) which saves you a few bytes when throwing result into Memcache. Mysqlnd handles multi result sets from prepared statements, libmysql didn’t until 5.5. PDO_MYSQL significantly improved due to mysqlnd development… and, and, and.
In my defense I don’t work as a full-time PHP developer day by day. I’m working with 2 year old code, and there is no existing reference to mysqlnd. (so in my eyes, let’s say I didn’t even know it existed)
Sometimes you have to work with what you have, not what you want. At the time I was unable to use MySQL 5.5.8 with PHP and so my headline correctly states that.
I have come to understand more, with thanks to Justin and several non post emails about that.
I’ve tried his recommendation and I’ve sought to understand more about mysqlnd and how to benefit from it. It you have some good reference material or recommendations about it specifically please provide. As such I now have a working environment with modified installation instructions and so I’ve adjusted my title to reflect more information I now know about the problem. (i.e. not known at time).
FYI I also ran my syntax by another MySQL DBA, and they didn’t point out mysqlnd either.
It would help if your this passionate to better promote mysqlnd over mysql and mysqli, to ensure people with older environments are aware of this.
As I am now more educated I will as you say try it out.
I can’t put something in a bad light when I can state I was unaware of it or I was following existing procedures which work perfectly fine with other MySQL versions.
What about the new native php client mysqlnd rather than libmysql?
Did you ever find a resolution to this issue? I am experiencing the same thing, even with the latest versions of PHP and MySQL