2.9. MySQL Installation Using a Source Distribution

1. Download and install Cygwin from http://cygwin.com.

2. Make sure gcc and make have been installed under Cygwin. You can test this by issuing which gcc and which make commands. If either one is not installed, run Cygwin's package manager, select gcc, make, or both, and install them.

3. Under Cygwin, execute these commands:

   shell> sh bk-client.shar
   shell> cd bk_client-1.1
   

   Then edit the Makefile and change the line that reads $(CC) $(CFLAGS) -o sfio -lz sfio.c to this:

   $(CC) $(CFLAGS) -o sfio sfio.c -lz
   

   Now run the make command and set the path:

   shell> make all
   shell> PATH=$PWD:$PATH
   

1. Change location to the directory you want to work from, and then use the following command to make a local copy of the MySQL 5.0 branch:

   shell> sfioball -r+ bk://mysql.bkbits.net/mysql-5.0 mysql-5.0
   

   In the preceding example, the source tree is set up in the mysql-5.0/ subdirectory of your current directory.

   The initial download of the source tree may take a while, depending on the speed of your connection. Please be patient.

2. You need GNU make, autoconf 2.58 (or newer), automake 1.8, libtool 1.5, and m4 to run the next set of commands. Even though many operating systems come with their own implementation of make, chances are high that the compilation fails with strange error messages. Therefore, it is highly recommended that you use GNU make (sometimes named gmake) instead.

   Fortunately, a large number of operating systems ship with the GNU toolchain preinstalled or supply installable packages of these. In any case, they can also be downloaded from the following locations:

   • http://www.gnu.org/software/autoconf/

   • http://www.gnu.org/software/automake/

   • http://www.gnu.org/software/libtool/

   • http://www.gnu.org/software/m4/

   • http://www.gnu.org/software/make/

   To configure MySQL 5.0, you also need GNU bison 1.75 or later. Older versions of bison may report this error:

   sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded
   

   Note: The maximum table size is not actually exceeded; the error is caused by bugs in older versions of bison.

   The following example shows the typical commands required to configure a source tree. The first cd command changes location into the top-level directory of the tree; replace mysql-5.0 with the appropriate directory name.

   shell> cd mysql-5.0
   shell> (cd bdb/dist; sh s_all)
   shell> (cd innobase; autoreconf --force --install)
   shell> autoreconf --force --install
   shell> ./configure  # Add your favorite options here
   shell> make
   

   Or you can use BUILD/autorun.sh as a shortcut for the following sequence of commands:

   shell> aclocal; autoheader
   shell> libtoolize --automake --force
   shell> automake --force --add-missing; autoconf
   shell> (cd innobase; aclocal; autoheader; autoconf; automake)
   shell> (cd bdb/dist; sh s_all)
   

   The command lines that change directory into the innobase and bdb/dist directories are used to configure the InnoDB and Berkeley DB (BDB) storage engines. You can omit these command lines if you to not require InnoDB or BDB support.

   If you get some strange errors during this stage, verify that you really have libtool installed.

   A collection of our standard configuration scripts is located in the BUILD/ subdirectory. You may find it more convenient to use the BUILD/compile-pentium-debug script than the preceding set of shell commands. To compile on a different architecture, modify the script by removing flags that are Pentium-specific.

3. When the build is done, run make install. Be careful with this on a production machine; the command may overwrite your live release installation. If you have another installation of MySQL, we recommend that you run ./configure with different values for the --prefix, --with-tcp-port, and --unix-socket-path options than those used for your production server.

4. Play hard with your new installation and try to make the new features crash. Start by running make test. See Section 24.1.2, “MySQL Test Suite”.

5. If you have gotten to the make stage, but the distribution does not compile, please enter the problem into our bugs database using the instructions given in Section 1.8, “How to Report Bugs or Problems”. If you have installed the latest versions of the required GNU tools, and they crash trying to process our configuration files, please report that also. However, if you execute aclocal and get a command not found error or a similar problem, do not report it. Instead, make sure that all the necessary tools are installed and that your PATH variable is set correctly so that your shell can find them.

6. After initially copying the repository with sfioball to obtain the source tree, you should use update periodically to update your local copy. To do this any time after you have set up the repository, use this command:

   shell> update bk://mysql.bkbits.net/mysql-5.0
   

7. You can examine the change history for the tree with all the diffs by viewing the BK/ChangeLog file in the source tree and looking at the ChangeSet descriptions listed there. To examine a particular changeset, you would have to use the sfioball command to extract two particular revisions of the source tree, and then use an external diff command to compare them. If you see some funny diffs or code that you have a question about, do not hesitate to send email to the MySQL internals mailing list. See Section 1.7.1, “MySQL Mailing Lists”. Also, if you think you have a better idea on how to do something, send an email message to the list with a patch.

• If configure is run after it has previously been run, it may use information that was gathered during its previous invocation. This information is stored in config.cache. When configure starts up, it looks for that file and reads its contents if it exists, on the assumption that the information is still correct. That assumption is invalid when you reconfigure.

• Each time you run configure, you must run make again to recompile. However, you may want to remove old object files from previous builds first because they were compiled using different configuration options.

• If you get errors such as the ones shown here when compiling sql_yacc.cc, you probably have run out of memory or swap space:

  Internal compiler error: program cc1plus got fatal signal 11
  Out of virtual memory
  Virtual memory exhausted
  

  The problem is that gcc requires a huge amount of memory to compile sql_yacc.cc with inline functions. Try running configure with the --with-low-memory option:

  shell> ./configure --with-low-memory
  

  This option causes -fno-inline to be added to the compile line if you are using gcc and -O0 if you are using something else. You should try the --with-low-memory option even if you have so much memory and swap space that you think you can't possibly have run out. This problem has been observed to occur even on systems with generous hardware configurations, and the --with-low-memory option usually fixes it.

• By default, configure picks c++ as the compiler name and GNU c++ links with -lg++. If you are using gcc, that behavior can cause problems during configuration such as this:

  configure: error: installation or configuration problem:
  C++ compiler cannot create executables.
  

  You might also observe problems during compilation related to g++, libg++, or libstdc++.

  One cause of these problems is that you may not have g++, or you may have g++ but not libg++, or libstdc++. Take a look at the config.log file. It should contain the exact reason why your C++ compiler didn't work. To work around these problems, you can use gcc as your C++ compiler. Try setting the environment variable CXX to "gcc -O3". For example:

  shell> CXX="gcc -O3" ./configure
  

  This works because gcc compiles C++ source files as well as g++ does, but does not link in libg++ or libstdc++ by default.

  Another way to fix these problems is to install g++, libg++, and libstdc++. However, we recommend that you not use libg++ or libstdc++ with MySQL because this only increases the binary size of mysqld without providing any benefits. Some versions of these libraries have also caused strange problems for MySQL users in the past.

• If your compile fails with errors such as any of the following, you must upgrade your version of make to GNU make:

  making all in mit-pthreads
  make: Fatal error in reader: Makefile, line 18:
  Badly formed macro assignment
  

  Or:

  make: file `Makefile' line 18: Must be a separator (:
  

  Or:

  pthread.h: No such file or directory
  

  Solaris and FreeBSD are known to have troublesome make programs.

  GNU make 3.75 is known to work.

• If you want to define flags to be used by your C or C++ compilers, do so by adding the flags to the CFLAGS and CXXFLAGS environment variables. You can also specify the compiler names this way using CC and CXX. For example:

  shell> CC=gcc
  shell> CFLAGS=-O3
  shell> CXX=gcc
  shell> CXXFLAGS=-O3
  shell> export CC CFLAGS CXX CXXFLAGS
  

  See Section 2.1.2.5, “MySQL Binaries Compiled by MySQL AB”, for a list of flag definitions that have been found to be useful on various systems.

• If you get errors such as those shown here when compiling mysqld, configure did not correctly detect the type of the last argument to accept(), getsockname(), or getpeername():

  cxx: Error: mysqld.cc, line 645: In this statement, the referenced
       type of the pointer value ''length'' is ''unsigned long'',
       which is not compatible with ''int''.
  new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
  

  To fix this, edit the config.h file (which is generated by configure). Look for these lines:

  /* Define as the base type of the last arg to accept */
  #define SOCKET_SIZE_TYPE XXX
  

  Change XXX to size_t or int, depending on your operating system. (You must do this each time you run configure because configure regenerates config.h.)

• The sql_yacc.cc file is generated from sql_yacc.yy. Normally, the build process does not need to create sql_yacc.cc because MySQL comes with a pre-generated copy. However, if you do need to re-create it, you might encounter this error:

  "sql_yacc.yy", line xxx fatal: default action causes potential...
  

  This is a sign that your version of yacc is deficient. You probably need to install bison (the GNU version of yacc) and use that instead.

• On Debian Linux 3.0, you need to install gawk instead of the default mawk if you want to compile MySQL with Berkeley DB support.

• If you need to debug mysqld or a MySQL client, run configure with the --with-debug option, and then recompile and link your clients with the new client library. See Section E.2, “Debugging a MySQL Client”.

• If you get a compilation error on Linux (for example, SuSE Linux 8.1 or Red Hat Linux 7.3) similar to the following one, you probably do not have g++ installed:

  libmysql.c:1329: warning: passing arg 5 of `gethostbyname_r' from
  incompatible pointer type
  libmysql.c:1329: too few arguments to function `gethostbyname_r'
  libmysql.c:1329: warning: assignment makes pointer from integer
  without a cast
  make[2]: *** [libmysql.lo] Error 1
  

  By default, the configure script attempts to determine the correct number of arguments by using g++ (the GNU C++ compiler). This test yields incorrect results if g++ is not installed. There are two ways to work around this problem:

  • Make sure that the GNU C++ g++ is installed. On some Linux distributions, the required package is called gpp; on others, it is named gcc-c++.

  • Use gcc as your C++ compiler by setting the CXX environment variable to gcc:

    export CXX="gcc"
    

  You must run configure again after making either of those changes.

• On most systems, you can force MIT-pthreads to be used by running configure with the --with-mit-threads option:

  shell> ./configure --with-mit-threads
  

  Building in a non-source directory is not supported when using MIT-pthreads because we want to minimize our changes to this code.

• The checks that determine whether to use MIT-pthreads occur only during the part of the configuration process that deals with the server code. If you have configured the distribution using --without-server to build only the client code, clients do not know whether MIT-pthreads is being used and use Unix socket file connections by default. Because Unix socket files do not work under MIT-pthreads on some platforms, this means you need to use -h or --host with a value other than localhost when you run client programs.

• When MySQL is compiled using MIT-pthreads, system locking is disabled by default for performance reasons. You can tell the server to use system locking with the --external-locking option. This is needed only if you want to be able to run two MySQL servers against the same data files, but that is not recommended, anyway.

• Sometimes the pthread bind() command fails to bind to a socket without any error message (at least on Solaris). The result is that all connections to the server fail. For example:

  shell> mysqladmin version
  mysqladmin: connect to server at '' failed;
  error: 'Can't connect to mysql server on localhost (146)'
  

  The solution to this problem is to kill the mysqld server and restart it. This has happened to us only when we have forcibly stopped the server and restarted it immediately.

• With MIT-pthreads, the sleep() system call isn't interruptible with SIGINT (break). This is noticeable only when you run mysqladmin --sleep. You must wait for the sleep() call to terminate before the interrupt is served and the process stops.

• When linking, you might receive warning messages like these (at least on Solaris); they can be ignored:

  ld: warning: symbol `_iob' has differing sizes:
      (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
  file /usr/lib/libc.so value=0x140);
      /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
  ld: warning: symbol `__iob' has differing sizes:
      (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
  file /usr/lib/libc.so value=0x140);
      /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
  

• Some other warnings also can be ignored:

  implicit declaration of function `int strtoll(...)'
  implicit declaration of function `int strtoul(...)'
  

• We have not been able to make readline work with MIT-pthreads. (This is not necessary, but may be of interest to some.)

• Visual Studio .Net 2003 (7.1) compiler system

• Between 3GB and 5GB disk space.

• Windows XP, Windows 2000 or higher.

1. Obtain a Windows source distribution packaged by MySQL AB for the particular version of MySQL in which you are interested. These are available from http://dev.mysql.com/downloads/.

2. You can package a source distribution yourself from the latest BitKeeper developer source tree. If you plan to do this, you must create the package on a Unix system and then transfer it to your Windows system. (Some of the configuration and build steps require tools that work only on Unix.) The BitKeeper approach thus requires:

   • A system running Unix, or a Unix-like system such as Linux.

   • BitKeeper installed on that system. See Section 2.9.3, “Installing from the Development Source Tree”, for instructions how to download and install BitKeeper.

Note: VC++ workspace files for MySQL 4.1 and above are compatible with Microsoft Visual Studio 7.1 and tested by MySQL AB staff before each release.

Follow this procedure to build MySQL:

When you are satisfied that the programs you have built are working correctly, stop the server. Then install MySQL as follows:

Set up and start the server in the same way as for the binary Windows distribution. See Section 2.3, “Installing MySQL on Windows”.

To create a Windows source package from the current BitKeeper source tree, use the instructions here. This procedure must be performed on a system running a Unix or Unix-like operating system because some of the configuration and build steps require tools that work only on Unix. For example, the following procedure is known to work well on Linux.