Pre-requisites
This tutorial is aimed at Linux installations that has the standard development tools already installed. The INSTALL file in the source archives provides good details of the software required (e.g. gunzip, gcc 2.95.2+,make).
Create a separate user for this development work.
su - useradd mysqldev su - mysqldev
Get an appropiate Snapshot
You can view recent snapshots at http://downloads.mysql.com/snapshots/mysql-5.1/.
The official statement on snapshots from MySQL AB.
Daily snapshot sources are only published, if they compiled successfully (using the BUILD/compile-pentium-debug-max script) and passed the test suite (using make test). If the source tree snapshot fails to compile or does not pass the test suite, the source tarball will not be published.
At the time of producing this the present snapshot was http://downloads.mysql.com/snapshots/mysql-5.1/mysql-5.1.12-beta-nightly-20060801.tar.gz
mkdir -p $HOME/src cd $HOME/src SNAPSHOT="mysql-5.1.12-beta-nightly-20060801";export SNAPSHOT wget http://downloads.mysql.com/snapshots/mysql-5.1/${SNAPSHOT}.tar.gz tar xfz ${SNAPSHOT}.tar.gz cd $SNAPSHOT
Compiling
You can for example do the simple way with most C programs:
DEPLOY=${HOME}/deploy; export DEPLOY ./configure --prefix=${DEPLOY} make make install
However it’s recommended you use the significant number of pre-configured build scripts found in the BUILD directory. For Example:
./BUILD/compile-pentium-debug --prefix=${DEPLOY}
I always get the following warnings. Not sure what to do about it, but it doesn’t break any future work to date. Surely somebody in the development team knows about them.
../build_win32/include.tcl: no such file or directory cp: cannot create regular file `../test/logtrack.list': No such file or directory
Testing
The easy, but time consuming part over, let’s test this new beast.
make install
This will deploy to the preconfigured area of $USER/deploy. For multiple versions within this process you should adjust this back in the compile process.
cd $DEPLOY bin/mysql_install_db bin/mysqld_safe & bin/mysql -e "SELECT VERSION()" bin/mysqladmin -uroot shutdown
Changes
So if you haven’t already sniffed around there are some reasonable changes in the structure. Here are a few points that caught me out:
- mysql_install_db is now under /bin not /scripts, infact there is no /scripts
- mysqld is not under /bin but infact under /libexec. A good reason to always used mysqld_safe
- by default the data directory is /var, normal documentation etc always has this as /data
This is a quick confirm it all works, and I’ve for the purposes of this example ensured that no other MySQL installation is running, and there is no default /etc/my.cnf file. (I always place this in the MySQL installation directory anyway).
Some minonr considerations for improvements with locations, users and multiple instances.
cd $DEPLOY rm -rf var bin/mysql_install_db --datadir=${DEPLOY}/data --user=$USER bin/mysqld_safe --basedir=${DEPLOY} --datadir=${DEPLOY}/data --user=$USER --port=3307 --socket=/tmp/mysqldev.sock & bin/mysql -P3307 -S/tmp/mysqldev.sock -e "SELECT VERSION()" bin/mysqladmin -P3307 -S/tmp/mysqldev.sock -uroot shutdown
Troubleshooting
Now, there is no guarantee that the snapshot is a working one, in the case of mysql-5.1.12-beta-nightly-20060801 in this example, it didn’t work for me? I’ve just reinstalled my OS to Fedora Core 5, and the previous source version (a 5.1.10 snapshot worked ok)
Here are some tips to help out.
The preconfigured BUILD scripts have a nice display option with -n that allows you to see what will happen.
./BUILD/compile-pentium-debug --prefix=${DEPLOY} -n
In my case it gave me this:
testing pentium4 ... ok gmake -k distclean || true /bin/rm -rf */.deps/*.P config.cache storage/innobase/config.cache storage/bdb/build_unix/config.cache bdb/dist/autom4te.cache autom4te.cache innobase/autom4te.cache; path=./BUILD . "./BUILD/autorun.sh" CC="gcc" CFLAGS="-Wimplicit -Wreturn-type -Wswitch -Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare -Wwrite-strings -Wunused -DUNIV_MUST_NOT_INLINE -DEXTRA_DEBUG -DFORCE_INIT_OF_VARS -DSAFEMALLOC -DPEDANTIC_SAFEMALLOC -DSAFE_MUTEX" CXX="gcc" CXXFLAGS="-Wimplicit -Wreturn-type -Wswitch -Wtrigraphs -Wcomment -W -Wchar-subscripts -Wformat -Wparentheses -Wsign-compare -Wwrite-strings -Wctor-dtor-privacy -Wnon-virtual-dtor -felide-constructors -fno-exceptions -fno-rtti -DUNIV_MUST_NOT_INLINE -DEXTRA_DEBUG -DFORCE_INIT_OF_VARS -DSAFEMALLOC -DPEDANTIC_SAFEMALLOC -DSAFE_MUTEX" CXXLDFLAGS="" ./configure --prefix=/home/mysqldev/deploy --enable-assembler --with-extra-charsets=complex --enable-thread-safe-client --with-readline --with-big-tables --with-debug=full --enable-local-infile gmake -j 4
In my case this helped with my problem, that is the autorun.sh command is throwing an error in the Innodb configuration.
Part of the compiling is you can turn Innodb off with –without-innodb, but the BUILD scripts don’t accept parameters, so it’s a matter of ignoring the autorun.sh command above, and adding –without-innodb to the configure.
As it turned out, the autorun.sh provided the additional storage engine support.
Details of the problem in this instance.
[mysqldev@lamda mysql-5.1.12-beta-nightly-20060801]$ . "./BUILD/autorun.sh" Updating Berkeley DB source tree permissions... ../build_win32/include.tcl: no such file or directory Updating Berkeley DB README file... Building ../README autoconf: building aclocal.m4... autoconf: running autoheader to build config.hin... autoconf: running autoconf to build configure Building ../test/logtrack.list cp: cannot create regular file `../test/logtrack.list': No such file or directory Building ../build_win32/db.h configure.in:723: required file `zlib/Makefile.in' not found Can't execute automake
The good news is today, the MySQL Barcamp was announced, a great place to get some better insite into the gurus of the MySQL internals. At least a place to ask these questions providing they have a beginner group.
My Next Tutorial will take a look at the example provided by Brian Aker at the recent MySQL Users Conference HackFest B: Creating New SHOW Commands.
LenZ says
In the section “Get an appropriate snapshot” you write:
At this time, there is no guarantee that a snapshot will compile. There are documented occurances of BitKeeper producing an invalid archive. In addition, snapshots are not verified prior to being made available..
This is not correct. Daily snapshot sources are only published, if they compiled successfully (using the BUILD/compile-pentium-debug-max script) and passed the test suite (using make test). If the source tree snapshot fails to compile or does not pass the test suite, the source tarball will not be published.
Bye,
LenZ
bx_ says
There are no src snapshots for 5.0 and 5.1 versions in the specified path now! Only for 4.1 and older. Generating of snapshots was discontinued or no one of the snapshots passes the compilation and testing, so they aren’t published? Don’t think, the last statement is right.
Ronald says
Dave Collins at sharewarepromotions.com also writes Warning: New AdWords phishing and the MySQL saga.