I’ve been trying very hard to find a proper solution for the challenge being put up by MySQL. Up untill now we had to compile the installation of MySQL by hand to get the proper shared libraries to be able to compile PHP, Postfix and all the rest without a problem. After extensive testing on my test server I found that the binary installation of MySQL 5.1.34 works without a problem which would cease the need to compile MySQL again.
The problem is that the binary releases use a different layout of the libraries and include files then the source release and I haven’t found a way to solve this issue yet without manually moving the files.
The binary release will put everything in ‘/usr/local/mysql/include‘ and ‘/usr/local/mysql/include‘ while the source code install will put everything in ‘/usr/local/mysql/include/mysql‘ and ‘/usr/local/mysql/include/mysql‘. There is a subtle difference but that difference will impact all the other compilation instructions on this site.
I wouldn’t mind going for the binary install procedure but MySQL has shown us that in the 5.0.x versions not release a binary package all the time but they will always have a source only release when they release. See also: How and When Updates Are Released.
I need you help on making some difficult choices:
- Just live with the binary versions and change the rest of the compile instructions to reflect the new locations of the files
- Keep using the MySQL compile instructions and keep everythign as is which means keep compiling MySQL to keep everythign working
- Use both methods independently, so use binary or source when needed and have seperate instructions for mysql source or binary installs for all the other stuff.
If you have another choice or solution to get the binary and source installations in sync I would love to hear about it.



10:43 pm
You could symlink the directories. Worked for me.
2:56 am
PostgreSQL?
7:40 pm
@Drew, that would be a very simple solution, but would that survive a binary install?
@Jeff, I’ve considered this but the implications are even bigger. Most people just want the MAMP stack so I need to add postgesql as an additional option. Also I’m not sure all components in the mailserver support this. But my hand might be forced to do this as Oracle now owns MySQL the future is uncertain.
2:33 am
I think it is a good idea to keep compiling MySQL for now. We can’t rely on getting a binary for every release or security update. We should wait and see what Oracle is going to do with MySQL.
1:34 pm
Hi Richard,
Installed package version of Mysql of 5.1.xx. But I saw that might give some issues to file locations. Now I want to revert back, any clue on how to remove this version of Mysql of my system?
After that I’ll install package of 5.0.81 and recompile source of the same version so I can use your instructions accordingly
Thanks for a reply
4:15 pm
I think it’s better to keep compiling MySQL. It’s not difficult and you wouldn’t need to change the instructions.
4:36 pm
Luc, You can keep 5.1 installed, compile the latest 5.1.x version with this:
./configure –prefix=/usr/local/mysql \
–with-server-suffix=-standard \
–enable-thread-safe-client \
–enable-local-infile \
–enable-shared \
–with-zlib-dir=bundled \
–with-big-tables \
–with-readline \
–with-plugins=all \
–without-docs
And everything will be allright. Still need to properly document this, but it has been tested.