Compiling and installing *MySQL*
********************************

* Menu:

* Getting it::                  How do I get *MySQL*?
* Which version::               Which *MySQL* version should I use?
* Many versions::               How/when will you release updates?
* Which OS::                    Which operating systems does *MySQL* support?
* Installing-source::           Compiling *MySQL* from source code.
* Installation problems::       Problems compiling ?
* Compilation-notes::           General compilation notes
* MIT-pthreads::                MIT-pthreads notes. (FreeBSD)
* Perl-installation::           Perl installation comments.
* Machine-OS::                  Special thing to consider with some machine/OS combinations.
* Win32::
* Install-binary::              Installation instructions for *MySQL* binary release
* mysql_install_db::            Problems running mysql_install_db
* Starting MySQL::              Problems starting *MySQL*
* Automatic start::             Automatic start/stop of *MySQL*


How do I get *MySQL*?
=====================

   You can always check *MySQL*'s home page (http://www.tcx.se/) to
read the latest news.

   But since the Internet connection at TcX is not very fast we would
*prefer* if you do the actual downloading from one of the mirrors below.

   Europe:
   *    Austria WWW [Univ. of      Technology/Vienna] (http://gd.tuwien.ac.at/db/mysql/)

   *    Bulgaria FTP [Naturella] (ftp://ftp.ntrl.net/pub/mirror/mysql)

   *    Czech Republic WWW [CESNET] (http://mirror.opf.slu.cz/mysql/)

   *    Denmark WWW [Ake] (http://mysql.ake.dk)

   *    Denmark WWW [SunSITE] (http://SunSITE.auc.dk/mysql/)

   *    Denmark FTP [SunSITE]
     (ftp://SunSITE.auc.dk/pub/databases/mysql/)

   *    Estonia WWW [Tradenet] (http://mysql.tradenet.ee)

   *    France WWW [minet] (http://www.minet.net/devel/mysql/)

   *    Germany      WWW [Wolfenbuettel] (http://www.fh-wolfenbuettel.de/ftp/pub/database/mysql/)

   *    Germany WWW [Staufen] (http://mysql.staufen.de/)

   *    Hungary WWW      [Xenia] (http://xenia.sote.hu/ftp/mirrors/www.tcx.se-mysql/)

   *    Israel WWW [Netvision] (http://mysql.netvision.net.il/)

   *    Israel FTP      [Netvision] (ftp://mysql.netvision.net.il/mirrors/mysql/)

   *    Italy WWW [Matrice] (http://www.matrice.it/risorse/mysql/)

   *    Poland WWW [Sunsite] (http://sunsite.icm.edu.pl/mysql/)

   *    Poland FTP [Sunsite] (ftp://sunsite.icm.edu.pl/pub/unix/mysql/)

   *    Portugal WWW [Telenet] (http://mysql.telenet.pt)

   *    Russia FTP [Cityline] (ftp://ftp-mysql.cityline.ru/pub/MySQL)

   *    Romania WWW [Timisoara] (http://www.dnttm.ro/mysql)

   *    Romania FTP [Timisoara] (ftp://ftp.dnttm.ro/pub/mysql)

   *    Romania WWW [Bucharest] (http://www.lbi.ro/MySQL)

   *    Romania FTP [Bucharest] (ftp://ftp.lbi.ro/mirrors/ftp.tcx.se)

   *    Sweden WWW [Sunet] (http://ftp.sunet.se/pub/unix/databases/relational/mysql/)

   *    Sweden      FTP [Sunet] (ftp://ftp.sunet.se/pub/unix/databases/relational/mysql/)

   *    UK WWW [Omnipotent/UK] (http://mysql.omnipotent.net/)

   *    UK FTP [Omnipotent/UK] (ftp://mysql.omnipotent.net/)

   *    UK WWW [PLiG/UK] (http://ftp.plig.org/pub/mysql/)

   *    UK FTP [PLiG/UK] (ftp://ftp.plig.org/pub/mysql/)

   North America:
   *    Canada WWW [Polaris Computing] (http://mysql.polaris.ca/)

   *    Canada WWW [Tryc] (http://web.tryc.on.ca/mysql/)

   *    Canada WWW [Cyberus] (http://mysql.cyberus.ca/)

   *    Canada FTP [Cyberus] (ftp://mysql.cyberus.ca/)

   *    USA WWW [Hurricane Electric/San Jose] (http://mysql.he.net)

   *    USA WWW [Buoy/New York] (http://www.buoy.com/mysql/)

   *  USA WWW [Hypernet      Communications/Dallas] (http://epsilon.hpnc.com/mysql)

   *  USA WWW [Hurricane Electric/California] (http://mysql.he.net)

   *    USA FTP [Netcasting/West      Coast] (ftp://ftp.netcasting.net/pub/mysql/)

   *    USA WWW [Savages/Oregon] (http://mysql.savages.com)

   *    USA WWW [Circle Net/North Carolina] (http://www.mysql.net)

   *    USA WWW [Gina net/Florida] (http://www.gina.net/mysql/)

   *    USA FTP      [DIGEX] (ftp://ftp.digex.net/pub/database/mysql/index.html)

   Asia:
   *    Korea WWW [KREONet] (http://linux.kreonet.re.kr/mysql/)

   *    Japan WWW [HappySize] (http://www.happysize.co.jp/mysql/)

   *    Japan FTP [HappySize] (ftp://ftp.happysize.co.jp/pub/mysql/)

   *    Singapore WWW [Com5 Productions] (http://mysql.com5.net)

   *    Singapore FTP [Com5 Productions] (ftp://ftp.com5.net/pub/mysql)

   *    Taiwan WWW [NCTU] (http://www.iem.nctu.edu.tw/data/mysql)

   Australia:
   *    Australia WWW [Blue Planet/Melbourne] (http://mysql.bluep.com/)

   *    Australia FTP [Blue      Planet/Melbourne] (ftp://mysql.bluep.com/mirror1/mysql/)

   *    Australia FTP      [Sage] (ftp://ftp.sage-au.org.au/pub/database/mysql)


Which *MySQL* version should I use?
===================================

   The first decision is if you want to use the latest development
release or the last stable release.

   Normally if you are starting with development we recommend going with
the development release. This is because there are usually no really bad
bugs in the development release and you can easily test it on your
machine with the crash-me and benchmark tests. *Note Benchmarks::.

   The second decision is if you want a source or a binary release.

   If you want to run *MySQL* on a platform that has a current binary
release, use that. A binary version of *MySQL* is easier to install.

   If you want to read (and/or modify) the C and C++ code that makes up
*MySQL* you should always get a source distribution. The code is always
the ultimate manual. The source distribution also contains more tests
and examples than the binary distribution.

   To clarify our naming schema:

   All *MySQL* versions are run through our standard test and the
benchmarks to ensure that they are relatively safe to use.  The standard
tests are also extended the whole time to test for all previously found
bugs, so it gets better the whole time.

   The *MySQL* release numbers consist of 3 numbers and a suffix.

   So a release name like `mysql-3.21.17-beta' means.

The first number. In this case 3
     This describes the file format. So all version 3 releases has the
     same file format. And when a version 4 appears every table has to
     be converted to the new format (Nice tools for this will of course
     be included).

The second number. In this case 21
     This is the release level. Normally there are two to choose from.
     One is the release/stable branch and the other is the development
     branch. Normally both are stable but the development version may
     have quirks, missing documentation and may fail to compile on some
     systems.

The third number. In this case 17
     This is the version number. This is incremented for each release.
     Usually you want the latest version for the release you have
     choosen.

The suffix. In this case beta
        * Alpha means that some new large code section exists which
          hasn't been tested to 100%. Known bugs should be documented
          in the News section (usually there are none). There are also
          new commands and extensions in most alpha releases.

        * Beta means that all new code has been tested. No major new
          things are added. There should be no known bugs.

        * Gamma is a beta that has been around a while and seems to
          work fine.  This is what many other companies call a release.

        * Release (no extension) means that the version has been run
          for a while at many different sites without any bug reports
          (Except platform-specific bugs).

   Note that all releases have at least been tested with:

A internal testsuite
     This is part of a production system for a customer. It has many
     tables and with many megabytes of data and lots of tables.

The *MySQL* benchmark suite
     This runs a range of common queries. It is also a test to see
     whether the latest batch of optimisations actually made the code
     faster. *Note Benchmarks::.

The crash-me test
     This tries to find out what the database supports and which
     limitations it has. *Note Benchmarks::.

   Another test is our internal production. We usually use the latest
version for this (at least on one machine) and we have more than 100
gigabytes of data to work with.


How/when will you release updates?
==================================

   We are using the following policy when updating *MySQL*:

   Each minor update will increment the last number in the version
string. When there are major new features or minor incompatibilities
with previous versions, the second number in the version string will be
incremented. When the file format changes the first number will be
increased.

   * Stable tested releases are meant to appear about 1-2 times a year.
     But if small bugs are found, a release with only bug-fixes will be
     released.

   * Working releases are meant to appear about every 1-8 weeks.

   * Binary releases for some platforms will be made for major releases
     by us. Other people may make binary releases for other systems but
     probably less frequently.

   * We usually make patches available as soon as we have located and
     fixed small bugs.

   * For non-critical but annoying bugs, we will make patches available
     if they are sent to us. Otherwise we will combine many of them
     into a bigger patch.


Which operating systems does *MySQL* support?
=============================================

   We use GNU autoconf so it is possible to port *MySQL* to all modern
systems with working Posix threads and a C++ compiler. The client code
requires C++ but not threads. We use/develop the software ourselves
primarily on Sun Solaris (versions 2.5 & 2.6) and some on RedHat Linux
5.0.

   The following OS/thread packages have been reported to compile
*MySQL* successfully. Note that for many OSes the native thread support
only works in the latest versions.

   * Solaris 2.5 & 2.6 with native threads.

   * SunOS 4.x with the included MIT threads package.

   * BSDI 2.x with the included MIT threads package.

   * BSDI 3.0 and 3.1 native threads.

   * SGI IRIX 6.x with native threads.

   * AIX 4.x whith native threads.

   * DEC UNIX 4.x with native threads.

   * Linux 2.0+ with LinuxThreads 0.5, 0.6 and 0.7.

   * FreeBSD 2.x with the included MIT threads package.

   * FreeBSD 3.x with native threads.

   * SCO OpenServer with a recent port of the FSU-threads package.

   * NetBSD 1.3 Intel and NetBSD 1.3 Alpha.

   * Openbsd 2.1

   * HPUX 10.20 with the included MIT threads package.

   * Win95 and NT.  This version is currently only available for users
     with a *MySQL* license or *MySQL* email support.


Compiling *MySQL* from source code.
===================================

   What you need:

  1. GNU `gzip' to uncompress the distribution.

  2. A reasonable `tar' to unpack the distribution. GNU `tar' is known
     to work.

  3. A working ANSI `C++' compiler. gcc >= 2.7, SGI C++, SunPro C++ are
     some of the compilers that are known to work. `libg++' is not
     needed when using `gcc'.

  4. A good `make' program. If you have problems we recommend trying GNU
     `make'.

* Menu:

* Quick-install::               Quick installation overview.
* Applying patches::            Applying a patch


Quick installation overview.
----------------------------

   Unpack tar archive in a directory. The tar file should be named like
mysql-VERSION.tar.gz (VERSION is a number like 3.21.30). A directory
named mysql-VERSION should be created.

`zcat mysql-VERSION.tar.gz | tar xvf -'
     Unpack the distribution into the current directory.

`cd mysql-VERSION'
     Change directory.

`./configure'
     Configure the release. Here you might want to add some options.
     For a list of configure options use `./configure --help'.

`make'
     Compile everything.

`make install'
     Install everything.

`./scripts/mysql_install_db'
     Set up the *MySQL* privilige tables. This only needs to be done
     the first time you install *MySQL*. You may want to edit this
     script before running it to get right initial permissions for
     users to connect to the database.

`'installation_directory'/bin/mysqladmin version'
     Check to see if the server is running. Unless you added some
     options to `./configure' 'installation_directory' is `/usr/local'.
     Here is an example of the output you should get (You will not get
     this exactly!):
          mysqladmin  Ver 6.3 Distrib 3.21.17, for pc-linux-gnu on i686
          TCX Datakonsult AB, by Monty
          
          Server version          3.21.17-alpha
          Protocol version        10
          Connection              Localhost via UNIX socket
          TCP port                3306
          UNIX socket             /tmp/mysql.sock
          Uptime:                 16 sec
          
          Running threads: 1  Questions: 20  Reloads: 2  Open tables: 3

   Remember that if you reconfigure *MySQL* you have to do `rm
config.cache' or `make distclean' before doing a new configure!

   Usual configure switches:
   * To compile only the client use `--without-server'. If you only
     want to have the client library and don't have a C++ compiler, you
     can remove the code in configure (in the source distribution) that
     tests for the C++ compiler and then compile with -without-server.
     Ignore in this case any warnings about `mysql.cc' (The only
     *MySQL* client that needs C++).

   * If you don't want to have your data under `/usr/local/var' use
     something like: `--prefix=/usr/local' or `--prefix=/usr/local
     --localstatedir=/usr/local/data/mysql'

   * If you don't want to have your sockets in the default place
     (default is `/tmp' or `/var/run') use
     `--with-unix-socket-path=absolute_file_name'

   * If you get errors compiling sql_yacc.yy errors like:

     `Internal compiler error: program cc1plus got fatal signal 11' or
     `Out of virtual memory' you can try the configure switch:
     `--with-low-memory'.  This adds `-fno-inline' to the compile line
     if you are using gcc and -O0 if you are using something else. The
     problem is that gcc requires about 180M to compile sql_yacc.cc
     with inline functions.

   * Changing the default character set.

     By default *MySQL* will use the ISO8859-1 (Latin1) character set.
     You may change this at compile time by the configure switch
     `--with-charset=charset'.

     Where [charset] may be one of: `big5', `czech', `dec8', `dos',
     `german1', `hp8', `koi8_ru', `latin1', `latin2', `swe7', `usa7',
     `ujis', or `sjis'.

     If you want to add another character set to *MySQL* you must:
        * Choose a name. CHARSET_NAME

        * Create the file
          `mysql_source_directory/strings/ctype-$CHARSET_NAME.c'.

        * Look at one of the existing ctype files to see what needs to
          be defined. Note that the arrays in this file must have names
          like ctype_$CHARSET_NAME, to_lower_$CHARSET_NAME and so on.

        * Add to include/m_ctype.h.in a unique number for the char set.

        * Add charset name to `CHARSETS_AVAILABLE' list in
          `configure'.in

        * Recompile and test

        *  If you are making a multiple-character char set, you can use
     the _MB macros.  In `strings/m_ctype.h.in' add:

          #define MY_CHARSET_<C>		X
          #if MY_CHARSET_CURRENT == MY_CHARSET_<C>
          #define USE_MB
          #define USE_MB_IDENT
          #define ismbchar(p, end)	(...)
          #define ismbhead(c)		(...)
          #define mbcharlen(c)		(...)
          #define MBMAXLEN		N
          #endif

     MY_CHARSET_<C>       unique value.                                   
     USE_MB               This charset have mb-char.                      
     USE_MB_IDENT:        Use mb-char as identifier. (optional)           
     ismbchar(p, e)       return 0 if not mb-char, or size of char if     
                          mb-char.  Check from (char*)p to (char*)e-1.    
     ismbhead(c)          Is c first char of mb or not?                   
     mbcharlen(c)         Size of char if c is first char of mb.          
     MBMAXLEN             Maximum size of one character.                  

     If you want to convert characters between the server and the
     client, you should take a look at the `SET OPTION CHARACTER SET'.
     *Note Set option::

     *Warning:* If you change character sets after having created a
     table you will have to run `isamchk -r -q' on every table.
     Otherwise things will be sorted incorecctly in some cases (but not
     all!).

   * For computer/OS specific switches, see the menu later in this
     chapter.

   GNU `make' is always recommended and is sometimes required.

   About creating the grants database `mysql_install_db':

   The default priviliges is that anybody may create/use the databases
named `test' or starting with `test_'. `root' can do anyting. *Note
Privileges::.

   To change the defaults edit the script before running it.  If this is
the first time you install *MySQL* you must run this command. If you
don't do it you will get the error: `Can't find file:
'./mysql/host.frm''. This script also starts the mysqld daemon the first
time.

   If you want to change things in the grant tables after installing you
should use `mysql -u root mysql' to connect to the grant tables as the
'root' user.

   Normal start of the *MySQL* server daemon (not needed the first
time): `'installation_directory'/bin/safe_mysqld --log'


Applying a patch
----------------

   Some times patches appear on the mailing list. To apply them, do
something like this:

     cd 'old-mysql-source-distribution-path'
     gunzip < patch-file-name.gz | patch -p1
     
     rm config.cache
     make clean

   And then follow the instructions for a normal source install from the
`./configure' step.

   And then restart your *MySQL* server.


Problems compiling ?
====================

   If your compile fails with something like:

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

   Try setting the environment variable `CXX' to `"gcc -O3"' (If you
are using `gcc').  For example `CXX="gcc -O3" ./configure'. If you use
this you don't nead to have libg++ installed!

   If you have any problems with using g++, or libg++ or libstdc++, you
can probably always solve these by configuring as above!

   You can also install libg++. By default `configure' picks `c++' as a
compiler name and GNU `c++' links with `-lg++'.

  1.      making all in mit-pthreads
          make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment
     This means you have to upgrade your make to GNU `make'.

  2. If you want to add flags to your C or C++ compiler, add the flags
     to the CC and CXX environment variables. For example:

          CC="gcc -O4"
          CXX="gcc -O4"
          export CC CXX

  3. If your `make' stops with `Can't find Makefile.PL' when you should
     try using GNU `make'. Solaris and FreeBSD are known to have
     troublesome `make' programs.

  4. If you get error messages from make or error message of type:
     `pthread.h: No such file or directory'

     This means you have to upgrade your `make' to GNU `make' (GNU
     `make' version 3.75 is known to work).

  5. If you get a error message like: `client/libmysql.c:273: parse
     error before `__attribute__''

     This means you need to upgrade your gcc compiler (2.7.2 is known
     to work).

  6. If configure fails, and you are going to mail <mysql@tcx.se>,
     please include any lines from config.log that you think can help
     solve the problem.  Also include a couple of lines of the last
     output from configure if configure aborts. Post the bug using the
     'mysqlbug' script.

     *PLEASE ALWAYS USE `mysqlbug'* when posting questions to
     <mysql@tcx.se>. *Note Bug reports::.

     Even if the problem isn't a bug, mysqlbug gathers some system
     information that will help others solve your problem!

  7. If you need to debug mysqld or a *MySQL* client, run configure
     with: `configure --with-debug=yes' and link your clients with the
     new client library.

     Before running a client you should do:
          MYSQL_DEBUG=d:t:O,/tmp/client.trace
          export MYSQL_DEBUG

     You will now get a trace file in `/tmp/client.trace'.

  8. If you get three errors when compiling mysqld like:
            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);

     Then configure didn't detect the type of the last argument to
     `accept()', `getsockname()' and `getpeername()'.  Search after the
     line:

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

     and change ### to size_t or int depending on your operating system.

  9. If you have problem with your own client code, test first with
     `mysql --debug=d:t:o,/tmp/client.trace' before mailing a bug
     report. *Note Bug reports::.


General compilation notes
=========================

   All *MySQL* programs compile clean (no warnings) for us (on Solaris
using gcc). But warning may appear because of different system include
files. Se below for warnings that may occur when using mit-pthreads.

   You probably have to use bison to compile sql_yacc.yy. If you get an
error like:
     "sql_yacc.yy", line xxx fatal: default action causes potential...
   you have to install bison (the GNU yacc).  Normally you don't have
to do this as *MySQL* comes with a already compiled sql_yacc.cc file.

   If you want to have static linked code, use (with gcc):
`LDFLAGS="-static" ./configure ...'


MIT-pthreads notes. (FreeBSD)
=============================

   You can on most systems force the usage of mit-pthreads with the
configure switch `--with-mit-threads'.

   Building in a non source directory is not supported when using
MIT-threads. This is because we want to keep our changes to this code
minimal.

   MIT-pthreads doesn't support the `AF_UNIX' protocol so we must use
the TCP/IP protocol for all connections (which is a little slower).  If
you can't connect to a table, try using the host (`-h' or `--host')
switch to `mysql'.  This must be done if you have compiled the client
code `--without-server' because the default connection is to use Unix
sockets.

   *MySQL* compiled with MIT threads has system locking disabled by
default for performance reasons. One can start the server with system
locking with the `--use-locking' switch.

   Sometimes (at least on Solaris) the pthread `bind()' command fails
to bind to a socket without any error message. The result of this is
that all connections to server fails.

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

   The solution to this is to kill the `mysqld' daemon and restart it.
This has only happened to us when we have forced the daemon down and
done a restart immediately.

   `sleep()' isn't interruptible with `SIGINT' (break) with
MIT-threads. This is only notable in `mysqladmin --sleep'. One must
wait for the end of the `sleep()' before the interrupt is served and
the process stops.

   We haven't got readline to work with MIT threads. (This isn't needed,
but may be interesting for someone)

   When linking (at least on Solaris) you will receive warning messages
like:

     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 which also can be ignored:

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


Perl installation comments.
===========================

   The included perl client code requires perl5.004 or later.

   If you got a the following error (from mysqlperl or DBD-mysql):

     /usr/bin/perl: can't resolve symbol '__moddi3'
     /usr/bin/perl: can't resolve symbol '__divdi3'

   You are probably using gcc (or using an old binary compiled with
gcc). Add `-L/usr/lib/gcc-lib/... -lgcc' to the link command where
`-L/...'  is the path to the directory where `libgcc.a' exists.

   If you want to use the perl module on a system that doesn't support
dynamic linking (like SCO) you can always make a static version of perl
with DBI and DBD-mysql:

   First you create a statically linked DBI by doing:
     perl Makefile.PL LINKTYPE=static
     make
     make install
     make perl

   After this you must install the new perl. The output of `make perl'
will contain the exact make command!  On SCO this is `make -f
Makefile.aperl inst_perl MAP_TARGET=perl'

   Next you create a statically linked DBD::mysql:
     perl Makefile.PL LINKTYPE=static
     make
     make install
     make perl

   You should also install the new perl (see the DBI perl installation
above).


Special things to consider for some machine/OS combinations.
============================================================

* Menu:

* Solaris::                     Solaris notes.
* SunOS::                       SunOS 4 notes.
* Linux::                       Linux notes for all versions
* Alpha-DEC-Unix::              Alpha-DEC-Unix notes.
* Alpha-DEC-OSF1::              Alpha-DEC-OSF1 notes.
* SGI-IRIX::                    SGI-IRIX notes.
* FreeBSD::                     FreeBSD notes.
* BSDI2::                       BSD/OS 2.# notes.
* SCO::                         SCO notes.
* IBM-AIX::                     IBM-AIX notes.
* HPUX::                        HPUX notes.


Solaris notes.
--------------

   Sun native threads only work on Solaris 2.5 and higher. For 2.4 and
earlier versions, you can use MIT-pthreads. *Note MIT-pthreads::.

   If there are too many processes that try to connect very rapidly to
the `mysqld' one will get `Error in accept : Protocol error' in the
mysql log.

   If you have the Sun Workshop 4.2 compiler you can configure with:
`CC=cc CFLAGS="-Xa -fast -xstrconst -mt" CXX=CC CXXFLAGS="-xsb -noex
-fast -mt" ./configure'

   You may also have to change the row in configure:

   `#if !defined(__STDC__) || __STDC__ != 1' to `#if
!defined(__STDC__)' because if you turn on `__STDC__' with the `-Xc'
switch, the Sun compiler can't compile with the Solaris `pthread.h'
header files anymore. This is a Sun bug (Broken compiler or broken
include file).

   If the compiled `mysqld' gives a error like: `libc internal error:
_rmutex_unlock: rmutex not held' you have tried to compile *MySQL* with
the Sun compiler without enabling the multi thread switch `-mt'. Add
`-mt' to CFLAGS and CXXFLAGS and try again.

   If you get the following error when compiling *MySQL* with gcc:

     gcc -O3 -g -O2 -DDBUG_OFF  -o thr_alarm ...
     ./thr_alarm.c: In function `signal_hand':
     ./thr_alarm.c:556: too many arguments to function `sigwait'

   This means that your gcc is not configured for your version of
Solaris!  The proper thing to do in this case is to get the newest egcs
or gcc version and compile this with your current gcc compiler!  At
least for Solaris 2.5, almost all binary versions of gcc have old,
unusable include files that will break all programs that use threads
(and possible other programs!)

   The tar in Solaris can't handle long file names;  You may get the
following error (or something similar) when unpacking the *MySQL*
distribution:

     x mysql-3.21.21a-beta-sun-solaris2.6-sparc/perl/Mysql-modules/blib/lib/auto/Msql-Mysql-modules, 0 bytes, 0 tape blocks
     tar: directory checksum error

   In this case you have to use gnu tar to unpack the distribution.
You can find copy of precompiled gnu tar (gtar) for Solaris at
`http://www.mysql.com/Downloads/'


SunOS 4 notes.
--------------

   On SunOS 4, MIT-pthreads is needed. You must have GNU `make' to
compile (because of MIT-pthreads).

   In readline you may get warnings about duplicate defines. These may
be ignored.

   When compiling mysqld there will be some warnings about `implicit
declaration of function'. These may be ignored.


Linux notes for all versions
----------------------------

   On Linux you should use the `--skip-locking' flag to `mysqld' if you
start it yourself. Normally the demon is started by `safe_mysqld' and
the flag is added automatically. This flag is needed because a bug in
Linux file locking calls. This bug is known to exist as recently as
Linux version 2.0.33.

   If you can't start mysqld or if mysql_install_db doesn't work, please
continue reading!  This only happens on Linux system with problems in
the Linuxthreads or libc/glibc library. There is a lot of simple
workarounds to get *MySQL* to work!  The simplest is to use the binary
version (not the RPM) of *MySQL* for Linux x86; One nice aspect of this
version is that it's probably 10% faster than any version you would
compile yourself!  *Note Compile and link options::

   When using LinuxThreads you will see a minimum of three processes
running. These are in fact threads. There will be one thread for the
Linux Threads manager, one thread to handle connections, and one thread
to handle alarms and signals.

   if you are using RedHat you might get errors like:

     /usr/bin/perl is needed...
     /usr/sh is needed...
     /usr/sh is needed...

   If so upgrade rpm itself to rpm-2.4.11-1.i386.rpm &
rpm-devel-2.4.11-1.i386.rpm (or later versions).

   You can get the 4.2 updates from
`ftp://ftp.redhat.com/updates/4.2/i386'. Or
`http://www.sunsite.unc.edu/pub/Linux/distributions/redhat/code/rpm/'
for other distributions.

* Menu:

* Linux-x86::                   Linux-x86 notes.
* Linux-Sparc::                 Linux-Sparc notes.
* Linux-Alpha::                 Linux-Alpha notes.


Linux-x86 notes.
................

   LinuxThreads should be installed before configuring *MySQL*!

   *MySQL* requires libc version 5.4.12 or newer. glibc version 2.0.6
and later should also work. There has been some problems with the glibc
rpms from RedHat so if you have problems, check if there are any
updates!

   On some older Linux distributions `configure' may give a error
about: `Syntax error in sched.h. Change _P to __P in the
/usr/include/sched.h file.\  See the Installation chapter in the
Reference Manual'. Just do what the error says and add a extra
underscore to the `_P' macro that only has one underscore. Then try
again.

   You may get some warnings when compiling: (these can be ignored)

     mysqld.cc -o objs-thread/mysqld.o
     mysqld.cc: In function `void init_signals()':
     mysqld.cc:315: warning: assignment of negative value `-1' to `long unsigned int'
     mysqld.cc: In function `void * signal_hand(void *)':
     mysqld.cc:346: warning: assignment of negative value `-1' to `long unsigned int'

   If you want in Debian GNU/Linux to get *MySQL* to auto start when
system boots, do the following:

     > cp scripts/mysql.server /etc/init.d/mysql.server
     > /usr/sbin/update-rc.d mysql.server defaults 99

   If mysqld always core dumps when starting, the problem may be that
you have an old `/lib/libc.a'.  Try renaming this, remove sql/mysqld
and do a new make install and try again.  This problem has been reported
on some Slackware installations. RedHat 5.0 has also a similar problem
with some new glibc versions. More about this later.

RedHat 5.0
..........

   If you install all the official redhat patches (including
glibc-2.0.6-9 and glibc-devel-2.0.6-9) it should work out of the box
(se above for how to configure).

   The updates are needed since there is a bug in glibc 2.0.5 in how
pthread_key_create variables are freed. With glibc 2.0.5 you must use
the static-linked *MySQL* binary distribution. If you want to compile
from source you must install the corrected version of Linuxthreads from
`http://www.tcx.se/Downloads/Linux' or upgrade your glibc.

   If you have a wrong glibc or linuxthread version the symptom is that
mysqld crashes after each connections. For example `mysqladmin version'
will crash mysqld when it finishes!

   Another symptom of wrong libraries is that mysqld crashes at once
when it starts. One some Linux systems this can be fixed by configuring
with `LDFLAGS=-static ./configure'.  On some RedHat 5.0 system it will
only work WITHOUT `LDFLAGS=-static'.  This is known to happen even with
new versions as glibc 2.0.7-4 !

   For the source distribution of glibc 2.0.7 you can find a patch at
`http://www.tcx.se/Download/Linux/glibc-2.0.7-total-patch.tgz' that is
easy to apply and is tested with `MySQL'!

   If you experience crashes like these when you build *MySQL*, you can
always download the newest binary version of *MySQL*.  This is compiled
staticly to avoid library conflicts and should work on all Linux
systems!

   If you want to compile this yourself, check how to debug mysqld!  As
*MySQL* comes with an internal debugger its very easy to get a trace
file that probably will help solve your problem very quickly!  *Note
Debugging::


Linux-Sparc notes.
..................

   In some implementations `readdir_r' is broken.  This will be noticed
when `SHOW DATABASES' always returns an empty set.  This can be fixed
by removing `HAVE_READDIR_R' from `config.h'.

   Some problems will require patching your Linux installation.  The
patch can be found at
`http://www.tcx.se/patches/Linux-sparc-2.0.30.diff'. This patch is
against the Linux distribution `sparclinux-2.0.30.tar.gz', that is
available at vger.rutgers.edu.  This is a version Lf linux which was
never merged with the official 2.0.30.  You must also install
linuxthreads 0.6 or newer.

   Thanks to jacques@solucorp.qc.ca for the above information.


Linux-Alpha notes.
..................

   The first problem is linuxthreads.  You must patch linuxthreads for
alpha because the RedHat distribution uses an old (broken) linuxthreads
version.

  1. Obtain the glibc2.5c source from any GNU ftp site.

  2. Get the file



     `ftp://www.tcx.se/pub/mysql/linux/patched-glibc-linuxthreads-0.6.tgz'.
     This includes a fixed .c file.  Copy this to the glibc
     `./linuxthreads' directory.

  3. Configure and compile glibc (You have to read the manual how to do
     this together with linuxthreads). Don't install this!

  4. Rename your old version of /usr/lib/libpthread.a to
     /usr/lib/libpthread.a-old

  5. Copy the file glibc.../linuxthreads/libpthread.a to /usr/lib.

  6. Configure *MySQL* with (everything on one row):
          CC=gcc CCFLAGS="-Dalpha_linux_port" CXX=gcc CXXFLAGS="-O3 -Dalpha_linux_port" ./configure --prefix=/usr/local/mysql

  7. Try to compile mysys/thr_lock and mysys/thr_alarm.  Test that these
     work!

  8. Recompile mysqld.

   Note that Alpha-Linux is still an alpha platform for *MySQL*.  With
RedHat 5.0 and the patched linuxthreads you have a very good chance of
it working.


Alpha-DEC-Unix notes.
---------------------

   When compiling threaded programs under Digital UNIX using CC / CXX
the documentation recommends the switch to cc and cxx and the libraries
`-lmach -lexc' (in addition to `-lpthread').

   So you have to configure with something like this:

   `CC="cc -pthread" CXX="cxx -pthread -O" ./configure
-with-named-thread-libs="-lpthread -lmach -lexc -lc"'

   When compiling mysqld you will may this warning for mysqld for a
couple of lines:

     mysqld.cc: In function void handle_connections()':
     mysqld.cc:626: passing long unsigned int *' as argument 3 of accept(int,sockad
     ddr *, int *)'

   You can safely ignore these. This is because configure can't detect
warnings, only errors.

   You may get problems with the server exiting directly. If so, try
starting it with `nohup safe_mysqld [options]'

   `nohup' is a command that ignores any `SIGHUP' sent from the
terminal.


Alpha-DEC-OSF1 notes.
---------------------

   If you have problems compiling and have Dec CC and gcc installed you
can try the following compile line (with sh or bash):

   CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 ./configure
-prefix=/usr/local/mysql

   On OSF1 V4.0D and compiler "DEC C V5.6-071 on Digital UNIX V4.0
(Rev. 878)" the compiler had some strange behaviour (One gets undefined
'asm' symbols).  /bin/ld appears also to be broken (one gets _exit
undefined when linking mysqld).  On this we have managed to compile
*MySQL* with the following configure line, after replacing /bin/ld from
OSF 4.0C:

   CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure -prefix=/usr/local/mysql

   In some versions of OSF1, the `alloca()' functions is broken. Fix
this by removing `'HAVE_ALLOCA'' from config.h.

   The `alloca()' function can also have a wrong prototype in
`/usr/include/alloca.h'.  This warning can be ignored.

   Configure will automaticly use the following thread libraries:
`-with-named-thread-libs="-lpthread -lmach -lexc -lc"'

   When using gcc you can also try to use:

   CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ....


SGI-IRIX notes.
---------------

   You may have to undefine some things in `config.h' (generated by
`./configure').

   In some Irix implementations the `alloca()' function is broken. If
the mysqld server dies on some selects, remove `HAVE_ALLOC' &
`HAVE_ALLOCA_H' from `config.h'.  If mysqladmin create doesn't work,
remove `HAVE_READDIR_R' from config.h. Also you may have to remove
`HAVE_TERM_H'.

   Irix 6.2 doesn't support POSIX threads out of of the box.  You have
install these patches, available from SGI if you have support:

   1403, 1404, 1644, 1717, 1918, 2000, 2044

   If you get the something like the following error when compiling
mysql.cc:

     "/usr/include/curses.h", line 82: error(1084): invalid combination of type

   Type the following in the mysql installation directory:

     > extra/replace bool curses_bool < /usr/include/curses.h > include/curses.h
     > make

   There have also been reports about scheduling problems. This is
because if only one thread is running, things go slow. Avoid this by
starting another client. This may lead to a 2-10 fold increase in
execution speed thereafter for the other thread.

   This is a poorly-understood problem with IRIS threads, so you may
have to improvise to find solutions until this can be fixed.

   If you are compiling with gcc, you can use the following configure
line:

   CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure -prefix=/usr/local/mysql
-with-thread-safe-client


FreeBSD notes.
--------------

   If you get a error on 'make install' that it can't find
/usr/include/pthreads, configure didn't detect that one neads
mit-threads on FreeBSD. This is fixed by doing:

     rm config.cache
     ./configure --with-mit-threads

   If you get link errors when compiling mysqlperl (Type
`ient.a(my_getwd.o): RRS text relocation at 0x9a9f for "__db_pargs_"')

   You must recompile the Perl code with `-DPIC -fpic'.

   Do the following:

  1. First install everything.

  2. Change in `client/Makefile' the line: `CFLAGS = -g -O2' to `CFLAGS
     = -O2 -DPIC -fpic'

  3. `cd client'

  4. `rm *.o'

  5. `make libmysqlclient.a'

  6. `cd ../perl'

  7. `make'

   This shall hopefully be handled automatically in the future.

   The FreeBSD `make' behaviour is slightly different from GNU `make'.
If you have a problem that `perl/Makefile' doesn't get generated, you
should install GNU `make'.

   If mysql or mysqladmin takes a long time to respond, a user said the
following:

   Are you running the ppp user process? On ine FreeBSD box (2.2.5)
MySQL clients takes a couple of seconds to connect to mysqld if the ppp
process is running.

   FreeBSD is also known to have a very low default file handle limit.
*Note Not enough file handles::

   If you have a problem that select NOW() returns GMT and not your
local time, you have to set the `TZ' environment variable to your
current timezone.

* Menu:

* FreeBSD-3.0::                 FreeBSD-3.0 notes.


FreeBSD-3.0 notes.
..................

   You have to configure with:

   `--with-named-thread-libs=-lc_r'

   The pthreads library for FreeBSD doesn't contain the `sigwait'
function and there is some bugs in it.  To fix this, get the
`FreeBSD-3.0-libc_r-1.0.diff' file and apply this in the
`/usr/src/lib/libc_r/uthread' directory. Follow after this the
instructions that can be found with `man pthread' about how to
recompile the `libc_r' library.

   You can test if you have a 'modern' `libpthread.a' with:

     > nm /usr/lib/libc_r.a | grep sigwait.

   If the above doesn't find `sigwait' you have to use the above patch
and recompile `libc_r'.


BSD/OS 2.# notes
----------------

   From Jan Legenhausen <jleg@csl-gmbh.net>.

   I finally got mysqlperl working on BSDI2.1.

   What i did was almost nothing:
  1. cd client

  2. Leave the Makefile as it is! (i use `GCC="shlicc2"' per default;
     perl5 automagically uses shlicc2 - you should use _one_ version
     (either `gcc' or `shlicc2') for both `Mysql.c' and
     `libmysqlclient.a'!)

  3. `rm *.o'

  4. `gmake libmysqlclient.a'

  5. `cd ../perl/mysqlperl'

  6. `make clean'

  7. add `$sysliblist=" -L$tmp -lgcc -lcompat";' to Makefile.PL line 45
     (just to be sure - i didn't check if one could leave out this one)

  8. `perl Makefile.PL'

  9. remove all old `libmysqlclient.a''s in `/usr/lib' and
     `/usr/contrib/lib'

 10. `make install'

   If you get the following error when compiling *MySQL*:

     item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)':
     item_func.h:28: virtual memory exhausted
     make[2]: *** [item_func.o] Error 1

   Then your ulimit for virtual memory is too low. Try using: `ulimit
-v 80000' and do `make' again.

   If you are using gcc you can also add the flag '-fno-inline' to the
compile line when compiling sql_yacc.cc.

   If you have a problem that select NOW() returns GMT and not your
local time, you have to set the `TZ' environment variable to your
current timezone.

* Menu:

* BSDI3::                       BSD/OS 3.# notes.


BSD/OS 3.# notes.
.................

  1. Upgrade to BSD/OS 3.1. If that is not possible, install BSDIpatch
     M300-038.

  2. Use the following configuration when installing *MySQL*:
          env CXX=shlicc++ CC=shlicc2 ./configure --prefix=/usr/local/mysql
          --localstatedir=/var/mysql --without-perl
          --with-unix-socket-path=/var/mysql/mysql.sock
     The following is also known to work:
          env CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
          --with-unix-socket-path=/var/mysql/mysql.sock

  3. If you have problems with performance under heavy load, try using
     the -skip-thread-prior switch to safe_mysqld!  This will run all
     threads with the same priority and on BSDI 3.1 this gives better
     performance.  (At least until BSDI has fixed their thread
     scheduler).

   You can change the directory locations if you wish, or just use their
defaults by not specifying them.


SCO notes.
----------

   The current port is only tested on a 'sco3.2v5.0.4' system.

  1. For OpenServer 5.0.X You need to use GDS in Skunkware 95 (95q4c).
     This is necessary because GNU gcc 2.7.2 in Skunkware 97 does not
     have GNU `as'.

  2. You need the port of GCC 2.5.? for this product and the
     Developement system.  They are required on this version of SCO
     UNIX.  You can not just use the GCC Dev system.

  3. One should get FSU thread package and install this first.  This
     can be found at:
     `http://www.cs.wustl.edu/~schmidt/ACE_wrappers/FSU-threads.tar.gz'
     You can also get a precompiled package from:
     `ftp://www.tcx.se/pub/mysql/Downloads/SCO/FSU-threads-3.5c.tar.gz'

  4. FSU pthreads can be compiled with SCO UNIX 4.2 with tcpip.  Or
     OpenServer 3.0 or Open Desktop 3.0 (OS 3.0 ODT 3.0), with the SCO
     Developement System installed using a good port of GCC 2.5.X ODT
     or OS 3.0 you will need a good port of GCC 2.5.? There are a lot
     of problems with out a good port.  The port for this product
     requires the SCO UNIX Developement system.  Without it, you are
     missing the libraries and the linker that is needed.

  5. To build FSU pthreads in your system do the following:
       1. Run ./configure in threads/src directory and select the SCO
          OpenServer option. This command copy Makefile.SCO5 to
          Makefile.

       2. Run make.

       3. To install in default /usr/include directory, login as root
          and cd to thread/src directory, run make install.

  6. Remember to use GNU `make' when making *MySQL*.

  7. If you don't start safe_mysqld as root, you will probably only get
     the default 110 open files per process.  mysqld will write a note
     about this in the log file.

   SCO development notes:

   * *MySQL* should automaticly detect FPU-threads and link mysqld
     with: `-lgthreads -lsocket -lgthreads'

   * The SCO development libraries are reentrant in FSU pthreads. SCO
     claims that its libraries function are reentrant so they must be
     reentrant with FSU pthreads. FSU pthreads on OpenServer tries to
     use the SCO scheme to make reentrant library.

   * FSU threads (at least the version at www.tcx.se) comes linked with
     GNU malloc.  If you get problems with memory usage, check that
     gmalloc.o is included in libgthreads.a and libgthreads.so

   * In FSU pthreads, the following system calls are pthread aware:
     read, write, getmsg, connect, accept, select and wait.


IBM-AIX notes.
--------------

   When using the IBM compiler, something like this is needed:

     CC="xlc_r -ma -O3 -qstrict" CXX="xlC_r -ma -O3 -qstrict" ./configure

   Automatic detection of xlC is missing from autoconf.


HPUX notes.
-----------

   There is a couple of 'small' problems when compiling mysql on HPUX.
Below we describe some problems and workarounds when using the HPUX
compiler and gcc 2.8.0 .

   gcc 2.8.0 can't compile readline on HPUX (internal compiler error).
mit-pthreads can't be compiled with HPUX compiler, because it can't
compile .S (assembler) files.

   We got *MySQL* to compile on HPUX 10.20 by doing the following:
     CC=cc CFLAGS="+z +e -Dhp9000s800 -D__hpux__" CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory
     cd mit-pthreads
     rm config.cache
     CC=gcc CXX=gcc ./configure
     cd ..
     make
     make install
     scripts/mysql_install_db


Win32 notes
===========

   The *MySQL*-win32 version has by now proven itself to be very
stable. The *MySQL*-win32 version has all the features as the
corresponding Unix version of *MySQL* with the following exceptions:

`ALTER TABLE'
     One can't do a `ALTER TABLE' on file if it is hold open by another
     thread or the table cache.  On *MySQL*-win32 I have added code to
     close the file owned by the thread that does `ALTER TABLE' but
     *MySQL* can't yet close the the file descriptors used by other
     threads. We have to do a major recode of the file lock system to
     handle this. For now, when using `ALTER TABLE', one must be sure
     that no other threads are using the table.  One can be sure of
     this by doing a 'mysqladmin refresh' before doing an `ALTER TABLE'.

`Increasing the table cache'
     Win32 has only a very limited number of open files it can handle
     at the the same time (about 255). Because of this one shouldn't
     increase the number of open connections or number of cached tables
     very much on Win32.

`Win95 and threads'
     Win95 leaks memory for each threads.  Because of this one shouldn't
     run mysqld for an extended time on Win95 if one does many
     connections as each connection in *MySQL* creates a new thread!
     NT doesn't suffer from this bug.

   Other win32 specific issues are described in the README file that
comes with the *MySQL*-win32 distribution.


Installation instructions for *MySQL* binary release
====================================================

   *Please* always use the mysqlbug script when posting questions to the
mailinglist (<mysql@tcx.se>). Even if the problem isn't a bug, mysqlbug
gathers some system information that will help other solve your
problem! *Note Bug reports::.

  1. Get the distribution. That is a file called something like
     mysql-version-OS.tgz. For example a file holding a *MySQL* version
     3.21.15 for a intel linux machine is called
     `mysql-3.21.15-alpha-pc-linux-gnu-i586.tgz'.

  2.  Pick a directory to put *MySQL* in: In the following we will use
     `/usr/local/mysql' as the installation directory and *MySQL*
     version VERSION (something like 3.21.15) for SunOS5 (Solaris), for
     example.

  3.  All of the following instructions assume you have permission to
     create files in `/usr/local'.

     Use the following commands to create the directory and unpack the
     distribution:

          > cd /usr/local
          > zcat /<where ever you put it>/mysql-3.20.0-SunOS5.tgz | tar xvf -
          > ln -s mysql-VERSION mysql

  4. After this you should install the *MySQL* privilege tables.

     In some binary versions the grant tables may already be created,
     for others distributions you should edit the
     `scripts/mysql_install_db' script to have the privileges you want
     and run it. The default privileges is that anybody may create/use
     the databases named 'test' or starting with "test_". The *MySQL*
     user root can do anything. Note that you do not have to run the
     *MySQL* server as root. Any user is ok as long as it can read and
     write in the installtion directories/files.

     If you want to recreate the privilege tables remove all the *.ISM
     and  *.ISD files in the mysql database directory, edit the
     scripts/mysql_install_db script to have the privileges you want
     and run it.

     This creates the privilige tables if they don't exist:
          > scripts/mysql_install_db

     *Note mysql_install_db::

     If you want to change things in the grant tables after installing
     you should use `mysql -u root mysql' to connect to the grant tables
     as the 'root' user.

     The `mysql_install_db' script also starts the `mysqld' daemon.

  5. Normally, start the *MySQL* server daemon (not needed the first
     time):

          > bin/safe_mysqld --log &

  6. You can test that the daemon is running by doing this:

          > bin/mysqladmin ver

     That should print something like this. The exact output depends on
     you platfrom and use.
          bin/mysqladmin  Ver 6.3 Distrib 3.21.15-alpha, for SOLARIS 2.5 on SPARCstation
          TCX Datakonsult AB, by Monty
          
          Server version          3.21.15-alpha
          Protocol version        9
          Connection              Localhost via UNIX socket
          TCP port                3306
          UNIX socket             /tmp/mysql.sock
          Uptime:                 2 days 1 hour 42 min 3 sec
          
          Running threads: 2  Questions: 450378  Reloads: 17  Open tables: 64

To get perl work do the following:
----------------------------------

     cd perl/DBI
     perl Makefile.PL
     make
     make install
     cd ../Mysql-modules
     perl Makefile.PL
     make
     make install

   You should use the `safe_mysqld' script to the server.
`safe_mysqld' expects one of two conditions to be true:

  1. You're executing the script from the base mysql installation
     directory (for example `/usr/local/mysql')

  2. The server should reside in `/my/'.  To get it to run correctly,
     you should cd to `/usr/local/mysql' and then execute `safe_mysqld'
     or modify the script so that it expects the base mysql directory
     to be `/usr/local/mysql' rather than the default `/my/'.

   When you execute this:

     > bin/mysqld --help

   You will get the options for mysqld (and safe_mysqld) and the current
paths. Normally you only should need to change the `--basedir=path'.
You can test the path switches by executing:

     > bin/mysqld --basedir=/usr/local --help

   If you would like to use mysqlaccess and have the mysql distribution
in some nonstandard place, you must change the path to mysql in
mysqlaccess. `bin/mysqlaccess' about line 308:

     $MYSQL = '/usr/local/bin/mysql --batch --unbuffered';

   If you don't change the path, you will get a 'broken pipe' error when
using mysqlaccess.

   If you would like *MySQL* to start when you boot your machine, you
can copy `bin/mysql.server' to where your system has it startup files.
More information can be bound in the bin/mysql.server script itself.

Linux notes.
------------

   * MySQL needs at least Linux 2.0.

   * The binary release is linked with -static, which means that you
     don't have to worry about which version of your system libraries.
     You don't have to install LinuxThreads either.  A program linked
     with -static is slightly bigger but also slighty faster (3-5%)
     than a dynamicly linked program. The only problem is that you
     can't use UDF (user definable functions) with a -static program.
     If you are going to write or use UDF functions (this is only
     something for C or C++ programmers) you have to compile *MySQL*
     yourself.

   * The Linux-intel binary release of MySQL is configured for the
     highest possible speed (we are even using the pentium compiler,
     pgcc):
          CC=gcc
          CFLAGS="-O6 -mpentium -mstack-align-double"
          CXX=gcc
          CXXFLAGS=-O6 -mpentium -mstack-align-double"
          LDFLAGS=-static
          ./configure --prefix=/usr/local/mysql

     All of the above is typed as one long line!

   * The perl distribution needs perl5.004.03 or newer.

HP/UX notes.
------------

   The binary distribution of *MySQL* for HP/UX is distributed as an HP
depot file.  This means that you must be running at least HP/UX 10.x to
have access to HP's software depot tools.

   This version of *MySQL* was compiled on an HP 9000/8xx server under
HP/UX 10.20, and uses MIT Pthreads. It is known to work well under this
configuration. This version does *not* use HP's native thread package.
It is highly unlikely that *MySQL* will use HP native threads on
anything but HP/UX 10.30 or later.

   Other configurations that may work:

   9000/7xx - HP/UX 10.20+ 9000/8xx - HP/UX 10.30 (does not use HP
native threads)

   The following configurations almost definitely won't work:

   9000/7xx or 8xx - HP/UX 10.x where x < 2 9000/7xx or 8xx - HP/UX 9.x

   To install (everything, including server, client and development
tools):

   /usr/sbin/swinstall -s <full path to the depot file> mysql.full

   To install server only:

   /usr/sbin/swinstall -s <full path to the depot file> mysql.server

   To install client pack only:

   /usr/sbin/swinstall -s <full path to the depot file> mysql.client

   To install development tools only:

   /usr/sbin/swinstall -s <full path to the depot file> mysql.developer

   The depot will place binaries/libraries in /opt/mysql and data in
/var/opt/mysql. The depot will also create the appropriate entries in
/sbin/init.d and /sbin/rc2.d to automatically start the server on boot.
This obviously entails being root to install.

Linking client libraries
------------------------

   Clients have to be linked with: `-lmysqlclient'


Problems running mysql_install_db
=================================

   It may happen that `mysql_install_db' doesn't install the privilige
tables but ends with:

     Starting mysql server
     starting mysqld demon with databases from xxxxxx
     mysql demon ended

   In this case you should examine the log in the xxxxxx directory very
carefully!  This contains the reason why mysqld didn't start.  If you
can't understand what happens, you should at least include the log when
you post a bug report using mysqlbug!

   Possible problems when running `mysql_install_db' are:

`There is already a mysqld deamon running.'
     In this case you have probably don't have to run mysql_install_db
     at all.  One only have to run mysql_install_db once when one
     install *MySQL* the first time.

`Installing a second mysqld daemon doesn't work when one daemon is running.'
     The problem is the new server tries to use the same socket and
     port as the old one.  You can start the new server with a
     different socket and port as follows:

          MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
          MYSQL_TCP_PORT=3307
          export MYSQL_UNIX_PORT MYSQL_TCP_PORT
          scripts/mysql_install_db

     After this you should edit your server boot script to start both
     daemon with different sockets and ports (safe_mysqld -socket=...
     -port=....).

`mysqld crashes at once.'
     If you are running RedHat 5.0 and a glibc version before glibc
     2.0.7-5 you should check that you have installed all glibc
     patches!  There is a lot of information about this in the `MySQL'
     mail archives.  *Note Linux::

`Can't connect to the server (when using mit-threads)'
     If `mysql_install_db' can't connect to the server you should check
     that you have an entry in `/etc/hosts' like:

          127.0.0.1		localhost
     The above is only a problem on system that doesn't have a thread
     library and *MySQL* has to use mit-threads.

`You don't have write access to create a socket file (in /tmp ?)'
     In this case you have to start mysqld manually and add the
     privilege information yourself. If you are using a binary version
     and are not installing in /usr/local/mysql, you have specify the
     paths mysqld should use with arguments.  You can get information
     about which paths mysqld uses and the how to change them with
     `mysqld --help'.  You can also specify paths for safe_mysqld by
     doing the following:

          MYSQL_UNIX_PATH=/some_directory_for_tmp_files/mysqld.sock
          MYSQL_TCP_PORT=3306
          TMPDIR=/some_directory_for_tmp_files/
          export MYSQL_UNIX_PATH MYSQL_TCP_PORT TMPDIR
          
          scripts/mysql_install_db
             or
          bin/mysqld --skip-grant
          
          bin/mysql -u root mysql
     After this you can execute the sql commands in mysql_install_db.

`The paths may be different from what mysqld expects.'
     You can override all paths to mysqld with command line arguments.
     Use `mysqld --help' for more information. You can edit
     bin/safe_mysqld to reflect the paths for your installation.

   A simple test to see that everything is working is: `bin/mysqladmin
version'


Problems starting *MySQL*
=========================

   Check the log file to see if mysqld started up correctly.

   `mysqld' daemon starts with a cd to 'mysql-data-dir'. After this,
mysqld-data-dir is changed to './' (current dir). All paths (databases,
pid file, and log file) have this directory as base path './'. If you
have any problems with wrong paths, try `mysqld --help' to see your
current paths. Every path can be changed by a startup option to
`safe_mysqld' or `mysqld'

     cd <localstatedir default /usr/local/var>
     tail <your host name>.log

   To verify that *MySQL* is working run the following tests:

     > cd /usr/local/bin
     > ./mysqlshow
     +-----------+
     | Databases |
     +-----------+
     | mysql     |
     +-----------+
     
     > ./mysqlshow mysql
     Database: mysql
     +--------+
     | Tables |
     +--------+
     | db     |
     | host   |
     | user   |
     +--------+
     
     > ./mysql -e "select host,db,user from db" mysql
     +------+--------+------+
     | host | db     | user |
     +------+--------+------+
     | %    | test   |      |
     | %    | test_% |      |
     +------+--------+------+

   There is also a benchmark suite so you can compare how *MySQL*
performs on different platforms. In the near future this will also be
used to compare *MySQL* to other SQL databases.

     > cd bench
     > run-auto-increment-test

   You can also run the tests in the test subdirectory. To run
`auto_increment.tst':

     ./mysql -vf test < ./tests/auto_increment.tst

   Expected results are shown in the file `./tests/auto_increment.res'.

   The safe_mysqld script is written that it should be able to start a
source and a binary version of mysqld, even if these have sligtly
different paths!

   You can install a binary release of *MySQL* anywhere as long as you
start safe_mysqld from installation directory:

     cd mysql_installation_directory
     bin/safe_mysqld &

   If you want to change the startup options to mysqld you can always
edit safe_mysqld!  In this case you should copy safe_mysqld to some
other location that it will not be overwritten if you sometimes decide
to upgrade MySQL!


Automatic start/stop of *MySQL*
===============================

   To start or stop *MySQL* use the following commands:

     scripts/mysql.server stop
     scripts/mysql.server start

   You might want to add these start and stop commands in the
appropriate places in your `/etc/rc*' files when you start using *MySQL*
for production applications.  You can edit the mysql.server script to
start safe_mysqld from some specific location and as some specific
user. You can also add startup options to mysqld here.

