Update 3 June 2008: We have removed the builds below, since they are quite obsolete and no one has posted comments about them since more than a year ago.

Great news are MySQL finally released new Community release – MySQL 5.0.33, which however as promised comes without Binaries.
This version also does not have any community patches yet, coming of the same tree as MySQL Enterprise.

To help those who would like to use MySQL Community version but does not like to build binaries we decided to publish our build for MySQL 5.0.33 Community release.

This build was done using “Generic Linux RPM” spec file on CentOS 4.4 (RHEL compatible) x86_64

(Links removed)

We added one more RPM to stantard MySQL RPMs – MySQL-microslow-5.0.33-0.glibc23.x86_64.rpm
This package contains mysqld-microslow binary, the server built with our microslow patch, which enables microsecound in slow-log.

More info about the patch

Also we propose Linux (AMD64 / Intel EM64T) binaries in tar.gz archive

(Link removed)

The archive contains both mysqld and mysqld-microslow binaries.

Source tar.gz with microslow patch

(Link removed)

The patch by itself

(Link removed)

We are waiting for your response if our binaries are helpful and if we should make binaries for other platforms / Linux distributions or if you would like to help us doing builds.

Newest Most Voted
Inline Feedbacks
View all comments
Scott MacVicar

I’ve already produced RHEL4 specific RPMS based on the official MySQL spec file they had for RHEL.

A windows build which I’ll zip up is also compiling as we speak.


Peter Zaitsev

Thank you Scott,

Your binaries are i386 though, the one we built are x86_64

The purpose of using general RPM specs to have them more suitable for other Linux versions.

Great you’re building Windows version.

Scott MacVicar

I had a generic build on i386 running but it stalled twice during the final packaging, I’ve kicked off another set on our RHEL4 box for the generic RPM version, should be done by the time I get home.

Monty Taylor

Do you guys have a version of this patch that works for 5.1 hiding around anywhere?


Good job, guys. I was looking for an i386 flavour too for my servers, and both your packages and Scott’s are downloading right now. Perhaps a single repo for future packages so you could distribute the workload…


I don’t seem to find anything in Scott’s WIN32 folder… But thanks anyway.
And yes, a common repository would be nice. On sourceforge.net, perhaps?

Scott MacVicar

A Windows 32 build is now in the process of being uploaded, its a MySQL-NT release build and a debug build is compiling, that will go up later.

I’ve also now included generic i386 rpm builds to go along with the RHEL4 specific i386 builds.


Thanks for these. They are GREAT appreciated! Hopefully you guys can bring us the latest RPMs/MySQL updates in the future too.


How does the configure lines looks like for the mysqlperformanceblog versions including CFLAGS etc?


Hmm so no gcc stuff like O3, march etc?

Peter Zaitsev

Vadim you did not mention CFLAGS and CPPFLAGS which are important part.

In any case it is same as setting “General RPM” which MySQL build team builds which means it should be reasonably optimized but with no special optimizations for Opteron or Intel Xeons.


I think it’s just -O2 -pipe -m64 (without -fomit-frame-pointer) if built on CentOS with rpmbuild, unless configured otherwise.

The myth that official RPMs are optimized is just a myth. 🙂 No one cares about extra 1% CPU time, so it’s optimized for compatibility.


Um… looks like directory settings:
are completely different to what we used to on RHEL4/CentOS4.

Peter Zaitsev

Alexey, I mean they should be reasonably well optimized. Normally 1-2 percent does not make so much difference especially on IO bound workloads 🙂

The directories are from “Generic RPM” which I guess is why they are different. It is build on CentOS but these are not CentOS RPMs.

Building ones with RHEL RPM Specs should be best if you want compatibility.


1% here, 1% there… and *poff* the binary becomes in the end twice as fast as the rpm version 😛

Peter Zaitsev


You may spend time rebuilding your binary hopping for massive boost. In practice if you have to changed complier few percent is maximum what you get.

There are many people who just like to build stuff on their own and looking for reasons why it must be done 🙂

James Day

Of course, if you do make it twice as fast, be sure to let MySQL know so it can be included in the normal release. 🙂



No binaries… but using our PCs for testing? 😕

James Day

Andrisi, it’s a build farm. This topic seems to be about building something.


Yes, yes I understand. Build something. Test the building procedure. And have binaries as byproducts?

BTW… I’m not an exprert in building MySQL, but as I imagagine, building installers (rpm or exe) can be automatized, isn’t it? Why is it such a big deal to do it? Could someone light me up (or us) in this? What are the difficulties beside having a proper build enviroment set up once?

Jason Frisvold

I think I missed the original announcement on this, so please forgive my confusion. Is MySQL not providing binaries any more for any community releases? Or will it only be specific releases?

ie, do I need to set up a build machine to continue using MySQL?


James Day

Jason, some community releases will be source only, some will be binary as well. A source build was released recently, I’m expecting (not guaranteed!) the next one sometime next month. The big schedule change has been the introduction of somewhat guaranteed monthly builds for Enterprise customers. Also the Community server builds will contain end user code that won’t be in the Enterprise releases because incorporating enhancements would breach their stability objective – which largely prohibits introducing non-bugfix code.

Andrisi, building is scripted but a full production release is actually lot of work and takes at least a week of some members of the build team’s time per release, so their time limits how many full builds can be done. Source releases are much less time-consuming and don’t tend to use resources needed by other ongoing builds that must be deconflicted. The work isn’t so much the builds, although they take a while, there’s also the testing and fixing of problems that show up in them and it’s really easy to underestimate how much time it takes.

Jason Frisvold


Thanks for the clarification. So community builds will tend to be more cutting edge and *possibly* less stable? ie, Fedora vs RHEL.

Enterprise releases won’t be available for general download in binary form? Or both binary and source?

Peter Zaitsev


The question of stability of Enterprise vs Community is good one, and the true answer will be – it is yet unknown. It will depend on number of factors, for example what kind of community patches MySQL will accept for community version, how solid they would be ? What kind of testing Enterprise version will get compared to Community – remember Enterprise goes out first as a binary, opposite to Fedora/Redhat case so Enterprise users will act as beta testers.

But as it is no there should not be much of the difference as Community and Enterprise is still the same source tree.

James Day

Jason, right. The Community builds will probably be a bit less stable. On the other hand, they will have user features before those features can be incorporated into the next release of the production server version. So today you can’t get a user feature into Enterprise 5.0 but you may well be able to get it into Community 5.0, because Community 5.0 can take more risks than Enterprise. Not being able to get things into the production releases has often irritated people who want to be closer to the cutting edge and this is one attempt at a solution. We’ll see how it works out. Hopefully it’ll show that those features are stable and really popular and they’ll be incorporated into the next full release.

Enterprise binaries will only be made available by MySQL to Enterprise customers, along with the source for anyone who wants it.

James Day

Vadim, I’m naturally an optimist and here I’m speaking in public so I have to try to be nice. 🙂 Besides, all I did was explain the plan. I don’t know if it will work, but it is the plan.

I have no good idea about how many community patches will be included in the next year. I would be surprised if it was more than 100 or less than 5. But maybe I will be surprised.


Hey dudes,

Is there anyway you can publish your spec file or src.rpm ? I want to recopile mysql 5.0.33 with sphinx SE.

Ronald Bradford

Hi Guys,

I’m trying to compile this under Solaris 10 AMD64 without success.
I can successfully compile MySQL 5.0.33 source.
Compiling your source gives the following error. Any clues into correct the openSSL problem would be greatly appreciated.

then mv -f “.deps/vio.Tpo” “.deps/vio.Po”; else rm -f “.deps/vio.Tpo”; exit 1; fi
In file included from vio_priv.h:24,
from vio.c:24:
../include/violite.h:95:30: openssl/opensslv.h: No such file or directory
../include/violite.h:106:25: openssl/ssl.h: No such file or directory
../include/violite.h:107:25: openssl/err.h: No such file or directory
In file included from vio_priv.h:24,
from vio.c:24:
../include/violite.h:111: error: syntax error before “SSL_CTX”
../include/violite.h:111: warning: no semicolon at end of struct or union
make[2]: *** [vio.o] Error 1