MySQL数据库

开发平台：

Visual C++

manual.txt：源码内容

*Note NetBSD::.
* OpenBSD > 2.5 with native therads. OpenBSD < 2.5 with the included
MIT-pthreads package. *Note OpenBSD::.
* OS/2 Warp 3, FixPack 29 and OS/2 Warp 4, FixPack 4. *Note OS/2::.
* SGI Irix 6.x with native threads. *Note SGI-Irix::.
* Solaris 2.5 and above with native threads on SPARC and x86. *Note
Solaris::.
* SunOS 4.x with the included MIT-pthreads package. *Note Solaris::.
* SCO OpenServer with a recent port of the FSU Pthreads package.
*Note SCO::.
* SCO UnixWare 7.0.1. *Note SCO Unixware::.
* Tru64 Unix
* Win95, Win98, NT, and Win2000. *Note Windows::.
Which MySQL Version to Use
==========================
The first decision to make is whether you want to use the latest
development release or the last stable release:
* Normally, if you are beginning to use *MySQL* for the first time
or trying to port it to some system for which there is no binary
distribution, we recommend going with the development release
(currently Version 3.23.35. This is because there are usually no
really serious bugs in the development release, and you can easily
test it on your machine with the `crash-me' and benchmark tests.
*Note Benchmarks::. Note that all *MySQL* releases are checked
with the *MySQL* benchmarks and an extensive test suite before
each release.
* Otherwise, if you are running an old system and want to upgrade,
but don't want to take chances with the development version, you
should upgrade to the latest in the same branch you are using
(where only the last version number is newer than yours). We have
tried to fix only fatal bugs and make small, relatively safe
changes to that version.
The second decision to make is whether you want to use a source
distribution or a binary distribution. In most cases you should
probably use a binary distribution, if there exist one for your
platform, as this is generally, it will be easier to install than a
source distribution.
In the following cases you will probably be better of with a source
installation:
* If you want to install *MySQL* at some explicit location. (The
standard binary distributions are 'ready to run' at any place, but
you may want to get even more flexibility).
* If you want to configure `mysqld' with some extra feature that is
NOT in the standard binary distributions. Here is a list of the
most common extra options that you may want to use
* -with-berkeley-db
* -with-raid
* -with-libwrap
* -with-named-z-lib (This is done for some of the binaries)
* -with-debugging[=full]
* The default binary distribution is normally compiled with support
for all characters sets and should work on a variety of processors
from the same processor family.
If you want a faster *MySQL* server you may want to recompile it
with support for only the character sets you need, use a better
compiler (like pgcc) or use compiler options that are better
optimized for your processor.
* If you have found a bug and reported it to the *MySQL* development
team you will probably got a patch that you need to apply to the
source distribution to get the bug fixed.
* If you want to read (and/or modify) the C and C++ code that makes
up *MySQL*, you should get a source distribution. The source code
is always the ultimate manual. Source distributions also contain
more tests and examples than binary distributions.
The *MySQL* naming scheme uses release numbers that consist of three
numbers and a suffix. For example, a release name like
`mysql-3.21.17-beta' is interpreted like this:
* The first number (`3') describes the file format. All Version 3
releases have the same file format. When a Version 4 appears, every
table will have to be converted to the new format (nice tools for
this will be included, of course.)
* The second number (`21') is the release level. Normally there are
two to choose from. One is the release/stable branch (currently
`22') and the other is the development branch (currently `23') .
Normally both are stable, but the development version may have
quirks, missing documentation on new features, or may fail to
compile on some systems.
* The third number (`17') is the version number within the release
level. This is incremented for each new distribution. Usually you
want the latest version for the release level you have choosen.
* The suffix (`beta') indicates the stability level of the release.
The possible suffixes are:
- `alpha' indicates that the release contains some large
section of new code that hasn't been 100% tested. Known bugs
(usually there are none) should be documented in the News
section. *Note News::. There are also new commands and
extensions in most alpha releases. Active development that
may involve major code changes can occur on an alpha release,
but everything will be tested before doing a release. There
should be no known bugs in any *MySQL* release.
- `beta' means that all new code has been tested. No major new
features that could cause corruption on old code are added.
There should be no known bugs. A version changes from alpha
to beta when there haven't been any reported fatal bugs
within an alpha version for at least a month and we don't
plan to add any features that could make any old command more
unreliable.
- `gamma' is a beta that has been around a while and seems to
work fine. Only minor fixes are added. This is what many
other companies call a release.
- If there is no suffix, it means that the version has been run
for a while at many different sites with no reports of bugs
other than platform-specific bugs. Only critical bug fixes
are applied to the release. This is what we call a stable
release.
All versions of *MySQL* are run through our standard tests and
benchmarks to ensure that they are relatively safe to use. Because the
standard tests are extended over time to check for all previously found
bugs, the test suite keeps getting better.
Note that all releases have been tested at least with:
An internal test suite
This is part of a production system for a customer. It has many
tables with hundreds of megabytes of data.
The *MySQL* benchmark suite
This runs a range of common queries. It is also a test to see
whether the latest batch of optimizations actually made the code
faster. *Note Benchmarks::.
The `crash-me' test
This tries to determine what features the database supports and
what its capabilities and limitations are. *Note Benchmarks::.
Another test is that we use the newest *MySQL* version in our internal
production environment, on at least one machine. We have more than 100
gigabytes of data to work with.
How and When Updates Are Released
=================================
*MySQL* is evolving quite rapidly here at MySQL AB and we want to share
this with other *MySQL* users. We try to make a release when we have
very useful features that others seem to have a need for.
We also try to help out users who request features that are easy to
implement. We take note of what our licensed users want to have, and we
especially take note of what our extended e-mail supported customers
want and try to help them out.
No one has to download a new release. The News section will tell you if
the new release has something you really want. *Note News::.
We use the following policy when updating *MySQL*:
* For each minor update, the last number in the version string is
incremented. When there are major new features or minor
incompatibilities with previous versions, the second number in the
version string is incremented. When the file format changes, the
first number is 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 distributions for some platforms will be made by us for
major releases. Other people may make binary distributions 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 larger patch.
* If there is, by any chance, a fatal bug in a release we will make
a new release as soon as possible. We would like other companies
to do this, too.
The current stable release is Version 3.23; We have already moved active
development to Version 4.0. Bugs will still be fixed in the stable
version. We don't believe in a complete freeze, as this also leaves
out bug fixes and things that "must be done." "Somewhat frozen" means
that we may add small things that "almost surely will not affect
anything that's already working."
Installation Layouts
====================
This section describes the default layout of the directories created by
installing binary and source distributions.
A binary distribution is installed by unpacking it at the installation
location you choose (typically `/usr/local/mysql') and creates the
following directories in that location:
*Directory* *Contents of directory*
`bin' Client programs and the `mysqld' server
`data' Log files, databases
`include' Include (header) files
`lib' Libraries
`scripts' `mysql_install_db'
`share/mysql' Error message files
`sql-bench' Benchmarks
A source distribution is installed after you configure and compile it.
By default, the installation step installs files under `/usr/local', in
the following subdirectories:
*Directory* *Contents of directory*
`bin' Client programs and scripts
`include/mysql' Include (header) files
`info' Documentation in Info format
`lib/mysql' Libraries
`libexec' The `mysqld' server
`share/mysql' Error message files
`sql-bench' Benchmarks and `crash-me' test
`var' Databases and log files
Within an installation directory, the layout of a source installation
differs from that of a binary installation in the following ways:
* The `mysqld' server is installed in the `libexec' directory rather
than in the `bin' directory.
* The data directory is `var' rather than `data'.
* `mysql_install_db' is installed in the `/usr/local/bin' directory
rather than in `/usr/local/mysql/scripts'.
* The header file and library directories are `include/mysql' and
`lib/mysql' rather than `include' and `lib'.
You can create your own binary installation from a compiled source
distribution by executing the script `scripts/make_binary_distribution'.
Installing a MySQL Binary Distribution
======================================
You need the following tools to install a *MySQL* binary distribution:
* GNU `gunzip' to uncompress the distribution.
* A reasonable `tar' to unpack the distribution. GNU `tar' is known
to work. Sun `tar' is known to have problems.
An alternative installation method under Linux is to use RPM (RedHat
Package Manager) distributions. *Note Linux-RPM::.
If you run into problems, *PLEASE ALWAYS USE* `mysqlbug' when posting
questions to <mysql@lists.mysql.com>. Even if the problem isn't a bug,
`mysqlbug' gathers system information that will help others solve your
problem. By not using `mysqlbug', you lessen the likelihood of getting
a solution to your problem! You will find `mysqlbug' in the `bin'
directory after you unpack the distribution. *Note Bug reports::.
The basic commands you must execute to install and use a *MySQL* binary
distribution are:
shell> groupadd mysql
shell> useradd -g mysql mysql
shell> cd /usr/local
shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell> ln -s mysql-VERSION-OS mysql
shell> cd mysql
shell> scripts/mysql_install_db
shell> chown -R root /usr/local/mysql
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql
shell> chown -R root /usr/local/mysql/bin/
shell> bin/safe_mysqld --user=mysql &
You can add new users using the `bin/mysql_setpermission' script if you
install the `DBI' and `Msql-Mysql-modules' Perl modules.
A more detailed description follows.
To install a binary distribution, follow the steps below, then proceed
to *Note Post-installation::, for post-installation setup and testing:
1. Pick the directory under which you want to unpack the
distribution, and move into it. In the example below, we unpack
the distribution under `/usr/local' and create a directory
`/usr/local/mysql' into which *MySQL* is installed. (The
following instructions therefore assume you have permission to
create files in `/usr/local'. If that directory is protected, you
will need to perform the installation as `root'.)
2. Obtain a distribution file from one of the sites listed in *Note
Getting *MySQL*: Getting MySQL.
*MySQL* binary distributions are provided as compressed `tar'
archives and have names like `mysql-VERSION-OS.tar.gz', where
`VERSION' is a number (for example, `3.21.15'), and `OS' indicates
the type of operating system for which the distribution is intended
(for example, `pc-linux-gnu-i586').
3. Add a user and group for `mysqld' to run as:
shell> groupadd mysql
shell> useradd -g mysql mysql
These commands add the `mysql' group and the `mysql' user. The
syntax for `useradd' and `groupadd' may differ slightly on
different Unixes. They may also be called `adduser' and
`addgroup'. You may wish to call the user and group something
else instead of `mysql'.
4. Change into the intended installation directory:
shell> cd /usr/local
5. Unpack the distribution and create the installation directory:
shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell> ln -s mysql-VERSION-OS mysql
The first command creates a directory named `mysql-VERSION-OS'.
The second command makes a symbolic link to that directory. This
lets you refer more easily to the installation directory as
`/usr/local/mysql'.
6. Change into the installation directory:
shell> cd mysql
You will find several files and subdirectories in the `mysql'
directory. The most important for installation purposes are the
`bin' and `scripts' subdirectories.
`bin'
This directory contains client programs and the server You
should add the full pathname of this directory to your `PATH'
environment variable so that your shell finds the *MySQL*
programs properly. *Note Environment variables::.
`scripts'
This directory contains the `mysql_install_db' script used to
initialize the server access permissions.
7. If you would like to use `mysqlaccess' and have the *MySQL*
distribution in some nonstandard place, you must change the
location where `mysqlaccess' expects to find the `mysql' client.
Edit the `bin/mysqlaccess' script at approximately line 18. Search
for a line that looks like this:
$MYSQL = '/usr/local/bin/mysql'; # path to mysql executable
Change the path to reflect the location where `mysql' actually is
stored on your system. If you do not do this, you will get a
`Broken pipe' error when you run `mysqlaccess'.
8. Create the *MySQL* grant tables (necessary only if you haven't
installed *MySQL* before):
shell> scripts/mysql_install_db
Note that *MySQL* versions older than Version 3.22.10 started the
*MySQL* server when you run `mysql_install_db'. This is no longer
true!
9. Change ownership of binaries to `root' and ownership of the data
directory to the user that you will run `mysqld' as:
shell> chown -R root /usr/local/mysql
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql
The first command changes the `owner' attribute of the files to the
`root' user, the second one changes the `owner' attribute of the
data directory to the `mysql' user, and the third one changes the
`group' attribute to the `mysql' group.
10. If you want to install support for the Perl `DBI'/`DBD' interface,
see *Note Perl support::.
11. If you would like *MySQL* to start automatically when you boot your
machine, you can copy `support-files/mysql.server' to the location
where your system has its startup files. More information can be
found in the `support-files/mysql.server' script itself and in
*Note Automatic start::.
After everything has been unpacked and installed, you should initialize
and test your distribution.
You can start the *MySQL* server with the following command:
shell> bin/safe_mysqld --user=mysql &
*Note safe_mysqld::.
*Note Post-installation::.
Linux RPM Notes
---------------
The recommended way to install *MySQL* on Linux is by using an RPM
file. The *MySQL* RPMs are currently being built on a RedHat Version
6.2 system but should work on other versions of Linux that support `rpm'
and use `glibc'.
If you have problems with an RPM file, for example, if you receive the
error "`Sorry, the host 'xxxx' could not be looked up'", see *Note
Binary notes-Linux::.
The RPM files you may want to use are:
* `MySQL-VERSION.i386.rpm'
The *MySQL* server. You will need this unless you only want to
connect to a *MySQL* server running on another machine.
* `MySQL-client-VERSION.i386.rpm'
The standard *MySQL* client programs. You probably always want to
install this package.
* `MySQL-bench-VERSION.i386.rpm'
Tests and benchmarks. Requires Perl and msql-mysql-modules RPMs.
* `MySQL-devel-VERSION.i386.rpm'
Libraries and include files needed if you want to compile other
*MySQL* clients, such as the Perl modules.
* `MySQL-VERSION.src.rpm'
This contains the source code for all of the above packages. It
can also be used to try to build RPMs for other architectures (for
example, Alpha or SPARC).
To see all files in an RPM package, run:
shell> rpm -qpl MySQL-VERSION.i386.rpm
To perform a standard minimal installation, run:
shell> rpm -i MySQL-VERSION.i386.rpm MySQL-client-VERSION.i386.rpm
To install just the client package, run:
shell> rpm -i MySQL-client-VERSION.i386.rpm
The RPM places data in `/var/lib/mysql'. The RPM also creates the
appropriate entries in `/etc/rc.d/' to start the server automatically
at boot time. (This means that if you have performed a previous
installation, you may want to make a copy of your previously installed
*MySQL* startup file if you made any changes to it, so you don't lose
your changes.)
After installing the RPM file(s), the `mysqld' daemon should be running
and you should now be able to start using *MySQL*. *Note
Post-installation::.
If something goes wrong, you can find more information in the binary
installation chapter. *Note Installing binary::.
Building Client Programs
------------------------
If you compile *MySQL* clients that you've written yourself or that you
obtain from a third party, they must be linked using the
`-lmysqlclient' option on the link command. You may also need to
specify a `-L' option to tell the linker where to find the library. For
example, if the library is installed in `/usr/local/mysql/lib', use
`-L/usr/local/mysql/lib -lmysqlclient' on the link command.
For clients that use *MySQL* header files, you may need to specify a
`-I' option when you compile them (for example,
`-I/usr/local/mysql/include'), so the compiler can find the header
files.
System-specific Issues
----------------------
The following sections indicate some of the issues that have been
observed on particular systems when installing *MySQL* from a binary
distribution.
Linux Notes for Binary Distributions
....................................
*MySQL* needs at least Linux Version 2.0.
The binary release is linked with `-static', which means you do not
normally need to worry about which version of the system libraries you
have. You need not install LinuxThreads, either. A program linked with
`-static' is slightly bigger than a dynamically linked program but also
slightly faster (3-5%). One problem, however, is that you can't use
user-definable functions (UDFs) with a statically linked program. If
you are going to write or use UDF functions (this is something only for
C or C++ programmers), you must compile *MySQL* yourself, using dynamic
linking.
If you are using a `libc'-based system (instead of a `glibc2' system),
you will probably get some problems with hostname resolving and
getpwnam() with the binary release. (This is because `glibc'
unfortunately depends on some external libraries to resolve hostnames
and getpwent() , even when compiled with `-static'). In this case you
probably get the following error message when you run
`mysql_install_db':
Sorry, the host 'xxxx' could not be looked up
or the following error when you try to run mysqld with the `--user'
option:
getpwnam: No such file or directory
You can solve this problem in one of the following ways:
* Get a *MySQL* source distribution (an RPM or the `tar.gz'
distribution) and install this instead.
* Execute `mysql_install_db --force'; This will not execute the
`resolveip' test in `mysql_install_db'. The downside is that you
can't use host names in the grant tables; you must use IP numbers
instead (except for `localhost'). If you are using an old *MySQL*
release that doesn't support `--force', you have to remove the
`resolveip' test in `mysql_install' with an editor.
* Start mysqld with `su' instead of using `--user'.
The Linux-Intel binary and RPM releases of *MySQL* are configured for
the highest possible speed. We are always trying to use the fastest
stable compiler available.
*MySQL* Perl support requires Version Perl 5.004_03 or newer.
On some Linux 2.2 versions, you may get the error `Resource temporarily
unavailable' when you do a lot of new connections to a `mysqld' server
over TCP/IP.
The problem is that Linux has a delay between when you close a TCP/IP
socket and until this is actually freed by the system. As there is only
room for a finite number of TCP/IP slots, you will get the above error
if you try to do too many new TCP/IP connections during a small time,
like when you run the *MySQL* `test-connect' benchmark over TCP/IP.
We have mailed about this problem a couple of times to different Linux
mailing lists but have never been able to resolve this properly.
The only known 'fix' to this problem is to use persistent connections in
your clients or use sockets, if you are running the database server and
clients on the same machine. We hope that the `Linux 2.4' kernel will
fix this problem in the future.
HP-UX Notes for Binary Distributions
....................................
Some of the binary distributions of *MySQL* for HP-UX is distributed as
an HP depot file and as a tar file. To use the depot file you must be
running at least HP-UX 10.x to have access to HP's software depot tools.
The HP 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. *MySQL* Version 3.22.26 and newer can also be built
with HP's native thread package.
Other configurations that may work:
* HP 9000/7xx running HP-UX 10.20+
* HP 9000/8xx running HP-UX 10.30
The following configurations almost definitely won't work:
* HP 9000/7xx or 8xx running HP-UX 10.x where x < 2
* HP 9000/7xx or 8xx running HP-UX 9.x
To install the distribution, use one of the commands below, where
`/path/to/depot' is the full pathname of the depot file:
* To install everything, including the server, client and
development tools:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.full
* To install only the server:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.server
* To install only the client package:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.client
* To install only the development tools:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.developer
The depot places binaries and libraries in `/opt/mysql' and data in
`/var/opt/mysql'. The depot also creates the appropriate entries in
`/etc/init.d' and `/etc/rc2.d' to start the server automatically at
boot time. Obviously, this entails being `root' to install.
To install the HP-UX tar.gz distribution, you must have a copy of GNU
`tar'.
Installing a MySQL Source Distribution
======================================
You need the following tools to build and install *MySQL* from source:
* GNU `gunzip' to uncompress the distribution.
* A reasonable `tar' to unpack the distribution. GNU `tar' is known
to work. Sun `tar' is known to have problems.
* A working ANSI C++ compiler. `gcc' >= 2.8.1, `egcs' >= 1.0.2, SGI
C++, and SunPro C++ are some of the compilers that are known to
work. `libg++' is not needed when using `gcc'. `gcc' 2.7.x has a
bug that makes it impossible to compile some perfectly legal C++
files, such as `sql/sql_base.cc'. If you only have `gcc' 2.7.x,
you must upgrade your `gcc' to be able to compile *MySQL*.
`gcc' >= 2.95.2 is recommended when compiling *MySQL* Version
3.23.x.
* A good `make' program. GNU `make' is always recommended and is
sometimes required. If you have problems, we recommend trying GNU
`make' 3.75 or newer.
If you run into problems, *PLEASE ALWAYS USE `mysqlbug'* when posting
questions to <mysql@lists.mysql.com>. Even if the problem isn't a bug,
`mysqlbug' gathers system information that will help others solve your
problem. By not using `mysqlbug', you lessen the likelihood of getting
a solution to your problem! You will find `mysqlbug' in the `scripts'
directory after you unpack the distribution. *Note Bug reports::.
Quick Installation Overview
---------------------------
The basic commands you must execute to install a *MySQL* source
distribution are:
shell> groupadd mysql
shell> useradd -g mysql mysql
shell> gunzip < mysql-VERSION.tar.gz | tar -xvf -
shell> cd mysql-VERSION
shell> ./configure --prefix=/usr/local/mysql
shell> make
shell> make install
shell> scripts/mysql_install_db
shell> chown -R root /usr/local/mysql
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql
shell> /usr/local/mysql/bin/safe_mysqld --user=mysql &
If you start from a source RPM, then do the following:
shell> rpm --rebuild MySQL-VERSION.src.rpm
This will make a binary RPM that you can install.
You can add new users using the `bin/mysql_setpermission' script if you
install the `DBI' and `Msql-Mysql-modules' Perl modules.
A more detailed description follows.
To install a source distribution, follow the steps below, then proceed
to *Note Post-installation::, for post-installation initialization and
testing:
1. Pick the directory under which you want to unpack the
distribution, and move into it.
2. Obtain a distribution file from one of the sites listed in *Note
Getting *MySQL*: Getting MySQL.
3. If you are interested in using Berkeley DB tables with MySQL, you
will need to obtain a patched version of the Berkeley DB source
code. Please read the chapter on Berkeley DB tables before
proceeding. *Note BDB::.
*MySQL* source distributions are provided as compressed `tar'
archives and have names like `mysql-VERSION.tar.gz', where
`VERSION' is a number like 3.23.35.
4. Add a user and group for `mysqld' to run as:
shell> groupadd mysql
shell> useradd -g mysql mysql
These commands add the `mysql' group, and the `mysql' user. The
syntax for `useradd' and `groupadd' may differ slightly on
different Unixes. They may also be called `adduser' and
`addgroup'. You may wish to call the user and group something
else instead of `mysql'.
5. Unpack the distribution into the current directory:
shell> gunzip < /path/to/mysql-VERSION.tar.gz | tar xvf -
This command creates a directory named `mysql-VERSION'.
6. Change into the top-level directory of the unpacked distribution:
shell> cd mysql-VERSION
Note that currently you must configure and build *MySQL* from this
top-level directory. You can not build it in a different
directory.
7. Configure the release and compile everything:
shell> ./configure --prefix=/usr/local/mysql
shell> make
When you run `configure', you might want to specify some options.
Run `./configure --help' for a list of options. *Note `configure'
options: configure options, discusses some of the more useful
options.
If `configure' fails, and you are going to send mail to
<mysql@lists.mysql.com> to ask for assistance, please include any
lines from `config.log' that you think can help solve the problem.
Also include the last couple of lines of output from `configure'
if `configure' aborts. Post the bug report using the `mysqlbug'
script. *Note Bug reports::.
If the compile fails, see *Note Compilation problems::, for help
with a number of common problems.
8. Install everything:
shell> make install
You might need to run this command as `root'.
9. Create the *MySQL* grant tables (necessary only if you haven't
installed *MySQL* before):
shell> scripts/mysql_install_db
Note that *MySQL* versions older than Version 3.22.10 started the
*MySQL* server when you run `mysql_install_db'. This is no longer
true!
10. Change ownership of binaries to `root' and ownership of the data
directory to the user that you will run `mysqld' as:
shell> chown -R root /usr/local/mysql
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql
The first command changes the `owner' attribute of the files to the
`root' user, the second one changes the `owner' attribute of the
data directory to the `mysql' user, and the third one changes the
`group' attribute to the `mysql' group.
11. If you want to install support for the Perl `DBI'/`DBD' interface,
see *Note Perl support::.
12. If you would like *MySQL* to start automatically when you boot your
machine, you can copy `support-files/mysql.server' to the location
where your system has its startup files. More information can be
found in the `support-files/mysql.server' script itself and in
*Note Automatic start::.
After everything has been installed, you should initialize and test your
distribution:
shell> /usr/local/mysql/bin/safe_mysqld --user=mysql &
If that command fails immediately with `mysqld daemon ended' then you
can find some information in the file
`mysql-data-directory/'hostname'.err'. The likely reason is that you
already have another `mysqld' server running. *Note Multiple servers::.
*Note Post-installation::.
Applying Patches
----------------
Sometimes patches appear on the mailing list or are placed in the
patches area (http://www.mysql.com/Downloads/Patches) of the *MySQL*
Web site.
To apply a patch from the mailing list, save the message in which the
patch appears in a file, change into the top-level directory of your
*MySQL* source tree, and run these commands:
shell> patch -p1 < patch-file-name
shell> rm config.cache
shell> make clean
Patches from the FTP site are distributed as plain text files or as
files compressed with `gzip'. Apply a plain patch as shown above for
mailing list patches. To apply a compressed patch, change into the
top-level directory of your *MySQL* source tree and run these commands:
shell> gunzip < patch-file-name.gz | patch -p1
shell> rm config.cache
shell> make clean
After applying a patch, follow the instructions for a normal source
install, beginning with the `./configure' step. After running the `make
install' step, restart your *MySQL* server.
You may need to bring down any currently running server before you run
`make install'. (Use `mysqladmin shutdown' to do this.) Some systems
do not allow you to install a new version of a program if it replaces
the version that is currently executing.
Typical `configure' Options
---------------------------
The `configure' script gives you a great deal of control over how you
configure your *MySQL* distribution. Typically you do this using
options on the `configure' command line. You can also affect
`configure' using certain environment variables. *Note Environment
variables::. For a list of options supported by `configure', run this
command:
shell> ./configure --help
Some of the more commonly-used `configure' options are described below:
* To compile just the *MySQL* client libraries and client programs
and not the server, use the `--without-server' option:
shell> ./configure --without-server
If you don't have a C++ compiler, `mysql' will not compile (it is
the one client program that requires C++). In this case, you can
remove the code in `configure' that tests for the C++ compiler and
then run `./configure' with the `--without-server' option. The
compile step will still try to build `mysql', but you can ignore
any warnings about `mysql.cc'. (If `make' stops, try `make -k' to
tell it to continue with the rest of the build even if errors
occur.)
* If you don't want your log files and database directories located
under `/usr/local/var', use a `configure' command, something like
one of these:
shell> ./configure --prefix=/usr/local/mysql
shell> ./configure --prefix=/usr/local
--localstatedir=/usr/local/mysql/data
The first command changes the installation prefix so that
everything is installed under `/usr/local/mysql' rather than the
default of `/usr/local'. The second command preserves the default
installation prefix, but overrides the default location for
database directories (normally `/usr/local/var') and changes it to
`/usr/local/mysql/data'.
* If you are using Unix and you want the *MySQL* socket located
somewhere other than the default location (normally in the
directory `/tmp' or `/var/run') use a `configure' command like
this:
shell> ./configure --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock
Note that the given file must be an absolute pathname!
* If you want to compile statically linked programs (for example, to
make a binary distribution, to get more speed, or to work around
problems with some RedHat distributions), run `configure' like
this:
shell> ./configure --with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
* If you are using `gcc' and don't have `libg++' or `libstdc++'
installed, you can tell `configure' to use `gcc' as your C++
compiler:
shell> CC=gcc CXX=gcc ./configure
When you use `gcc' as your C++ compiler, it will not attempt to
link in `libg++' or `libstdc++'.
Here is some common environment variables to set depending on the
compiler you are using:
gcc 2.7.2.1 CC=gcc CXX=gcc CXXFLAGS="-O6 -felide-constructors"
egcs 1.0.3a CC=gcc CXX=gcc CXXFLAGS="-O6 -felide-constructors
-fno-exceptions -fno-rtti"
gcc 2.95.2 CFLAGS="-O6 -mpentiumpro" CXX=gcc CXXFLAGS="-O6
-mpentiumpro -felide-constructors -fno-exceptions
-fno-rtti"
pgcc 2.90.29 CFLAGS="-O6 -mpentiumpro -mstack-align-double"
or newer CXX=gcc CXXFLAGS="-O6 -mpentiumpro
-mstack-align-double -felide-constructors
-fno-exceptions -fno-rtti"
In most cases you can get a resonable optimal *MySQL* binary
picking the options from the above and add the following options
to the configure line:
--prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static
The full configure line would in other words be something like the
following for all recent gcc versions:
CFLAGS="-O6 -mpentiumpro" CXX=gcc CXXFLAGS="-O6 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static
The binaries we provide at on the MySQL home site
`http://www.mysql.com', are all compiled with full optimization and
should be ok for most users. *Note MySQL binaries::. There is some
things one can tweak to make an even faster binary, but this is
only for advanced users. *Note Compile and link options::.
If the build fails and produces errors about your compiler or
linker not being able to create the shared library
`libmysqlclient.so.#' (`#' is a version number), you can work
around this problem by giving the `--disable-shared' option to
`configure'. In this case, `configure' will not build a shared
`libmysqlclient.so.#' library.
* You can configure *MySQL* not to use `DEFAULT' column values for
non-`NULL' columns (that is, columns that are not allowed to be
`NULL'). This causes `INSERT' statements to generate an error
unless you explicitly specify values for all columns that require a
non-`NULL' value. To suppress use of default values, run
`configure' like this:
shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure
* By default, *MySQL* uses the ISO-8859-1 (Latin1) character set. To
change the default set, use the `--with-charset' option:
shell> ./configure --with-charset=CHARSET
`CHARSET' may be one of `big5', `cp1251', `cp1257', `czech',
`danish', `dec8', `dos', `euc_kr', `gb2312', `gbk', `german1',
`hebrew', `hp8', `hungarian', `koi8_ru', `koi8_ukr', `latin1',
`latin2', `sjis', `swe7', `tis620', `ujis', `usa7', or
`win1251ukr'. *Note Character sets::.
If you want to convert characters between the server and the
client, you should take a look at the `SET OPTION CHARACTER SET'
command. *Note `SET OPTION': SET OPTION.
*Warning:* If you change character sets after having created any
tables, you will have to run `myisamchk -r -q' on every table. Your
indexes may be sorted incorrectly otherwise. (This can happen if
you install *MySQL*, create some tables, then reconfigure *MySQL*
to use a different character set and reinstall it.)
* To configure *MySQL* with debugging code, use the `--with-debug'
option:
shell> ./configure --with-debug
This causes a safe memory allocator to be included that can find
some errors and that provides output about what is happening.
*Note Debugging server::.
* If your client programs are using threads, you need to also
compile a thread-safe version of the *MySQL* client library with
the `--with-thread-safe-client' configure options. This will
create a `libmysqlclient_r' library with which you should link
your threaded applications. *Note Thread-safe clients::.
* Options that pertain to particular systems can be found in the
system-specific sections later in this chapter. *Note Source
install system issues::.
Installing from development source tree
=======================================
*CAUTION:* You should only read this section if you are interested in
helping us test our new code. If you just want to get *MySQL* up and
running on your system, you should use either source or binary
distribution.
Below are the instructions to obtain our most recent development source
tree:
* Download *BitKeeper* from
`http://www.bitmover.com/cgi-bin/download.cgi'. You will need
*Bitkeeper* 2.0 or newer to access our repository.
* Follow the instructions to install it.
* Once *BitKeeper* is installed, if you want to clone 3.23 branch,
`bk clone bk://work.mysql.com:7000 mysql', and `bk clone
bk://work.mysql.com:7001 mysql-4.0' for 4.0 branch
The initial download may take a while, depending on the speed of
your connection.
* You will need GNU autoconf/automake, libtool, and m4 to do the
next stage. If you get some strange error during the first stage,
check that you really have libtool installed!
cd mysql
bk -r edit
aclocal; autoheader; autoconf; automake;
./configure # Add your favorite options here
make
We have a collection of our standard configure scripts in the
`BUILD/' subdirectory - if you are lazy, you can do
`BUILD/compile-pentium-debug' . It will actually work on a lot of
non-x86 machines despite its name.
* Once the build is done, `make install'. Be careful with this on a
production machine - this may overwrite your live release binary.
We recommend that if you have another installation of *MySQL* that
you `./configure' with different values for `prefix', `tcp-port',
and `unix-socket-path'.
* Play hard with your new installation and try to make the new
features crash. Start by running `make test'. *Note MySQL test
suite::.
* If you have gotten to the `make' stage and it does not compile,
please report it to <bugs@lists.mysql.com>. If you have installed
the update version of the required GNU tools, and they crash
trying to process our configuration files, please report it also.
However, if you execute `aclocal' and get `command not found', or a
similar problem, do not report it - make sure all the needed tools
are installed and your `PATH' variable is set correctly.
* After the initial `bk clone', do `bk pull' to get the updates. If
you are using the most recent beta version of BitKeeper, you
should use `bk opull' instead.
* You can examine change history of the tree with all the diffs with
`bk sccstool'. If you see some funny diffs or code that you have a
question about, do not hesitate and e-mail
<internals@lists.mysql.com>. Also if you think you have a better
idea on how to do something, send an email to the same place with
a patch - `bk diffs' will produce a patch for you after you have
made changes to the source. If you do not have the time to code
your idea, just send a description.
* *BitKeeper* has a nice help utility - `bk helptool'.
Problems Compiling?
===================
All *MySQL* programs compile cleanly for us with no warnings on Solaris
using `gcc'. On other systems, warnings may occur due to differences in
system include files. See *Note MIT-pthreads::, for warnings that may
occur when using MIT-pthreads. For other problems, check the list
below.
The solution to many problems involves reconfiguring. If you do need to
reconfigure, take note of the following:
* If `configure' is run after it already has 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.
To prevent old configuration information or object files from being
used, run these commands before rerunning `configure':
shell> rm config.cache
shell> make clean
Alternatively, you can run `make distclean'.
The list below describes some of the problems compiling *MySQL* that
have been found to occur most often:
* If you get errors when compiling `sql_yacc.cc', such as the ones
shown below, you have probably run out of memory or swap space:
Internal compiler error: program cc1plus got fatal signal 11
or
Out of virtual memory
or
Virtual memory exhausted
The problem is that `gcc' requires huge amounts 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++ sources as well as `g++'
does, but does not link in `libg++' or `libstdc++' by default.
Another way to fix these problems, of course, is to install `g++',
`libg++' and `libstdc++'.
* 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' Version 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=-O6
shell> CXX=gcc
shell> CXXFLAGS=-O6
shell> export CC CFLAGS CXX CXXFLAGS
See *Note MySQL binaries::, for a list of flag definitions that
have been found to be useful on various systems.
* If you get an error message like this, you need to upgrade your
`gcc' compiler:
client/libmysql.c:273: parse error before `__attribute__'
`gcc' 2.8.1 is known to work, but we recommend using `gcc' 2.95.2
or `egcs' 1.0.3a instead.
* If you get errors such as those shown below when compiling
`mysqld', `configure' didn't 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. (Note that you will have to 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 doesn't need to create `sql_yacc.cc', because
*MySQL* comes with an already-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.
* If you need to debug `mysqld' or a *MySQL* client, run `configure'
with the `--with-debug' option, then recompile and link your
clients with the new client library. *Note Debugging client::.
MIT-pthreads Notes
==================
This section describes some of the issues involved in using
MIT-pthreads.
Note that on Linux you should NOT use MIT-pthreads but install
LinuxThreads! *Note Linux::.
If your system does not provide native thread support, you will need to
build *MySQL* using the MIT-pthreads package. This includes older
FreeBSD systems, SunOS 4.x, Solaris 2.4 and earlier, and some others.
*Note Which OS::.
* 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 or not 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 will not
know whether or not MIT-pthreads is being used and will use Unix
socket connections by default. Because Unix sockets do not work
under MIT-pthreads, this means you will need to use `-h' or
`--host' 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 `--use-locking' option.
* 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 is to kill the `mysqld' server and restart it.
This has only happened to us when we have forced the server down
and done a restart immediately.
* With MIT-pthreads, the `sleep()' system call isn't interruptible
with `SIGINT' (break). This is only noticeable 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 may 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 haven't gotten `readline' to work with MIT-pthreads. (This isn't
needed, but may be interesting for someone.)
Perl Installation Comments
==========================
Installing Perl on Unix
-----------------------
Perl support for *MySQL* is provided by means of the `DBI'/`DBD' client
interface. *Note Perl::. The Perl `DBD'/`DBI' client code requires
Perl Version 5.004 or later. The interface _will not work_ if you have
an older version of Perl.
*MySQL* Perl support also requires that you've installed *MySQL* client
programming support. If you installed *MySQL* from RPM files, client
programs are in the client RPM, but client programming support is in
the developer RPM. Make sure you've installed the latter RPM.
As of Version 3.22.8, Perl support is distributed separately from the
main *MySQL* distribution. If you want to install Perl support, the
files you will need can be obtained from
`http://www.mysql.com/Downloads/Contrib/'.
The Perl distributions are provided as compressed `tar' archives and
have names like `MODULE-VERSION.tar.gz', where `MODULE' is the module
name and `VERSION' is the version number. You should get the
`Data-Dumper', `DBI', and `Msql-Mysql-modules' distributions and
install them in that order. The installation procedure is shown below.
The example shown is for the `Data-Dumper' module, but the procedure is
the same for all three distributions:
1. Unpack the distribution into the current directory:
shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -
This command creates a directory named `Data-Dumper-VERSION'.
2. Change into the top-level directory of the unpacked distribution:
shell> cd Data-Dumper-VERSION
3. Build the distribution and compile everything:
shell> perl Makefile.PL
shell> make
shell> make test
shell> make install
The `make test' command is important because it verifies that the
module is working. Note that when you run that command during the
`Msql-Mysql-modules' installation to exercise the interface code, the
*MySQL* server must be running or the test will fail.
It is a good idea to rebuild and reinstall the `Msql-Mysql-modules'
distribution whenever you install a new release of *MySQL*,
particularly if you notice symptoms such as all your `DBI' scripts
dumping core after you upgrade *MySQL*.
If you don't have the right to install Perl modules in the system
directory or if you to install local Perl modules, the following
reference may help you:
`http://www.iserver.com/support/contrib/perl5/modules.html'
Look under the heading `Installing New Modules that Require Locally
Installed Modules'.
Installing ActiveState Perl on Windows
--------------------------------------
To install the *MySQL* `DBD' module with ActiveState Perl on Windows,
you should do the following:
* Get activestate perl from
`http://www.activestate.com/Products/ActivePerl/index.html' and
install it.
* Open a DOS shell.
* If required, set the HTTP_proxy variable. For example, you might
try: `set HTTP_proxy=my.proxy.com:3128'
* Start the PPM program: `C:perlbinppm.pl'
* If you have not already done so, install `DBI': `install DBI'
* If this succeeds, install
`ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd'
The above should work at least with ActiveState Perl Version 5.6.
If you can't get the above to work, you should instead install the
*MyODBC* driver and connect to *MySQL* server through ODBC:
use DBI;
$dbh= DBI->connect("DBI:ODBC:$dsn","$user","$password") ||
die "Got error $DBI::errstr when connecting to $dsnn";
Installing the MySQL Perl Distribution on Windows
-------------------------------------------------
The *MySQL* Perl distribution contains `DBI', `DBD:MySQL' and
`DBD:ODBC'.
* Get the Perl distribution for Windows from
`http://www.mysql.com/download.html'.
* Unzip the distribution in `C:' so that you get a `C:PERL'
directory.
* Add the directory `C:PERLBIN' to your path.
* Add the directory `C:PERLBINMSWIN32-x86-thread' or
`C:PERLBINMSWIN32-x86' to your path.
* Test that `perl' works by executing `perl -v' in a DOS shell.
Problems Using the Perl `DBI'/`DBD' Interface
---------------------------------------------
If Perl reports that it can't find the `../mysql/mysql.so' module, then
the problem is probably that Perl can't locate the shared library
`libmysqlclient.so'.
You can fix this by any of the following methods:
* Compile the `Msql-Mysql-modules' distribution with `perl
Makefile.PL -static -config' rather than `perl Makefile.PL'.
* Copy `libmysqlclient.so' to the directory where your other shared
libraries are located (probably `/usr/lib' or `/lib').
* On `Linux' you can add the pathname of the directory where
`libmysqlclient.so' is located to the `/etc/ld.so.conf' file.
* Add the pathname of the directory where `libmysqlclient.so' is
located to the `LD_RUN_PATH' environment variable.
If you get the following errors from `DBD-mysql', you are probably
using `gcc' (or using an old binary compiled with `gcc'):
/usr/bin/perl: can't resolve symbol '__moddi3'
/usr/bin/perl: can't resolve symbol '__divdi3'
Add `-L/usr/lib/gcc-lib/... -lgcc' to the link command when the
`mysql.so' library gets built (check the output from `make' for
`mysql.so' when you compile the Perl client). The `-L' option should
specify the pathname of the directory where `libgcc.a' is located on
your system.
Another cause of this problem may be that Perl and *MySQL* aren't both
compiled with `gcc'. In this case, you can solve the mismatch by
compiling both with `gcc'.
If you get the following error from `Msql-Mysql-modules' when you run
the tests:
t/00base............install_driver(mysql) failed: Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: ../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol: uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.
it means that you need to include the compression library, -lz, to the
link line. This can be doing the following change in the file
`lib/DBD/mysql/Install.pm':
$sysliblist .= " -lm";
to
$sysliblist .= " -lm -lz";
After this, you MUST run 'make realclean' and then proceed with the
installation from the beginning.
If you want to use the Perl module on a system that doesn't support
dynamic linking (like SCO) you can generate a static version of Perl
that includes `DBI' and `DBD-mysql'. The way this works is that you
generate a version of Perl with the `DBI' code linked in and install it
on top of your current Perl. Then you use that to build a version of
Perl that additionally has the `DBD' code linked in, and install that.
On SCO, you must have the following environment variables set:
shell> LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
or
shell> LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib
shell> LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib
shell> MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:/usr/skunk/man:
First, create a Perl that includes a statically linked `DBI' by running
these commands in the directory where your `DBI' distribution is
located:
shell> perl Makefile.PL -static -config
shell> make
shell> make install
shell> make perl
Then you must install the new Perl. The output of `make perl' will
indicate the exact `make' command you will need to execute to perform
the installation. On SCO, this is `make -f Makefile.aperl inst_perl
MAP_TARGET=perl'.
Next, use the just-created Perl to create another Perl that also
includes a statically-linked `DBD::mysql' by running these commands in
the directory where your `Msql-Mysql-modules' distribution is located:
shell> perl Makefile.PL -static -config
shell> make
shell> make install
shell> make perl
Finally, you should install this new Perl. Again, the output of `make
perl' indicates the command to use.
System-specific Issues
======================
The following sections indicate some of the issues that have been
observed to occur on particular systems when installing *MySQL* from a
source distribution.
Solaris Notes
-------------
On Solaris, you may run into trouble even before you get the *MySQL*
distribution unpacked! Solaris `tar' can't handle long file names, so
you may see an error like this when you unpack *MySQL*:
x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks
tar: directory checksum error
In this case, you must use GNU `tar' (`gtar') to unpack the
distribution. You can find a precompiled copy for Solaris at
`http://www.mysql.com/Downloads/'.
Sun native threads work only on Solaris 2.5 and higher. For Version 2.4
and earlier, *MySQL* will automatically use MIT-pt threads. *Note
MIT-pthreads::.
If you get the following error from configure:
checking for restartable system calls... configure: error can not run test
programs while cross compiling
this means that you have something wrong with your compiler
installation! In this case you should upgrade your compiler to a newer
version. You may also be able to solve this problem by inserting the
following row into the `config.cache' file:
ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}
If you are using Solaris on a SPARC, the recommended compiler is `gcc'
2.95.2. You can find this at `http://gcc.gnu.org/'. Note that `egs'
1.1.1 and `gcc' 2.8.1 don't work reliably on SPARC!
The recommended `configure' line when using `gcc' 2.95.2 is:
CC=gcc CFLAGS="-O6"
CXX=gcc CXXFLAGS="-O6 -felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --with-low-memory --enable-assembler
If you have a ultra sparc, you can get 4 % more performance by adding
"-mcpu=v8 -Wa,-xarch=v8plusa" to CFLAGS and CXXFLAGS.
If you have the Sun Workshop (SunPro) 4.2 (or newer) compiler, you can
run `configure' like this:
CC=cc CFLAGS="-Xa -fast -xO4 -native -xstrconst -mt"
CXX=CC CXXFLAGS="-noex -xO4 -mt"
./configure --prefix=/usr/local/mysql --enable-assembler
You may also have to edit the `configure' script to change this line:
#if !defined(__STDC__) || __STDC__ != 1
to this:
#if !defined(__STDC__)
If you turn on `__STDC__' with the `-Xc' option, the Sun compiler can't
compile with the Solaris `pthread.h' header file. This is a Sun bug
(broken compiler or broken include file).
If `mysqld' issues the error message shown below when you run it, you
have tried to compile *MySQL* with the Sun compiler without enabling the
multi-thread option (`-mt'):
libc internal error: _rmutex_unlock: rmutex not held
Add `-mt' to `CFLAGS' and `CXXFLAGS' and try again.
If you get the following error when compiling *MySQL* with `gcc', it
means that your `gcc' is not configured for your version of Solaris:
shell> 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'
The proper thing to do in this case is to get the newest version of
`gcc' and compile it 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
possibly other programs)!
Solaris doesn't provide static versions of all system libraries
(`libpthreads' and `libdl'), so you can't compile *MySQL* with
`--static'. If you try to do so, you will get the error:
ld: fatal: library -ldl: not found
If too many processes try to connect very rapidly to `mysqld', you will
see this error in the *MySQL* log:
Error in accept: Protocol error
You might try starting the server with the `--set-variable back_log=50'
option as a workaround for this. *Note Command-line options::.
If you are linking your own *MySQL* client, you might get the following
error when you try to execute it:
ld.so.1: ./my: fatal: libmysqlclient.so.#: open failed: No such file or directory
The problem can be avoided by one of the following methods:
* Link the client with the following flag (instead of `-Lpath'):
`-Wl,r/full-path-to-libmysqlclient.so'.
* Copy `libmysqclient.so' to `/usr/lib'.
* Add the pathname of the directory where `libmysqlclient.so' is
located to the `LD_RUN_PATH' environment variable before running
your client.
When using the `--with-libwrap' configure option, you must also include
the libraries that `libwrap.a' needs:
--with-libwrap="/opt/NUtcpwrapper-7.6/lib/libwrap.a -lnsl -lsocket
If you have problems with configure trying to link with `-lz' and you
don't have `zlib' installed, you have two options:
* If you want to be able to use the compressed communication
protocol, you need to get and install zlib from ftp.gnu.org.
* Configure with `--with-named-z-libs=no'.
If you are using gcc and have problems with loading `UDF' functions
into *MySQL*, try adding `-lgcc' to the link line for the `UDF'
function.
If you would like *MySQL* to start automatically, you can copy
`support-files/mysql.server' to `/etc/init.d' and create a symbolic
link to it named `/etc/rc3.d/S99mysql.server'.
Solaris 2.7/2.8 Notes
---------------------
You can normally use a Solaris 2.6 binary on Solaris 2.7 and 2.8. Most
of the Solaris 2.6 issues also apply for Solaris 2.7 and 2.8.
Note that *MySQL* Version 3.23.4 and above should be able to autodetect
new versions of Solaris and enable workarounds for the following
problems!
Solaris 2.7 / 2.8 has some bugs in the include files. You may see the
following error when you use `gcc':
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of the previous
definition
If this occurs, you can do the following to fix the problem:
Copy `/usr/include/widec.h' to `.../lib/gcc-lib/os/gcc-version/include'
and change line 41 from:
#if !defined(lint) && !defined(__lint)
to
#if !defined(lint) && !defined(__lint) && !defined(getwc)
Alternatively, you can edit `/usr/include/widec.h' directly. Either
way, after you make the fix, you should remove `config.cache' and run
`configure' again!
If you get errors like this when you run `make', it's because
`configure' didn't detect the `curses.h' file (probably because of the
error in `/usr/include/widec.h'):
In file included from mysql.cc:50:
/usr/include/term.h:1060: syntax error before `,'
/usr/include/term.h:1081: syntax error before `;'
The solution to this is to do one of the following:
* Configure with `CFLAGS=-DHAVE_CURSES_H CXXFLAGS=-DHAVE_CURSES_H
./configure'.
* Edit `/usr/include/widec.h' as indicted above and rerun configure.
* Remove the `#define HAVE_TERM' line from `config.h' file and run
`make' again.
If you get a problem that your linker can't find `-lz' when linking
your client program, the problem is probably that your `libz.so' file is
installed in `/usr/local/lib'. You can fix this by one of the
following methods:
* Add `/usr/local/lib' to `LD_LIBRARY_PATH'.
* Add a link to `libz.so' from `/lib'.
* If you are using Solaris 8, you can install the optional zlib from
your Solaris 8 CD distribution.
* configure *MySQL* with the `--with-named-z-libs=no' option.
Solaris x86 Notes
-----------------
If you are using `gcc' or `egcs' on Solaris x86 and you experience
problems with core dumps under load, you should use the following
`configure' command:
CC=gcc CFLAGS="-O6 -fomit-frame-pointer -DHAVE_CURSES_H"
CXX=gcc
CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -DHAVE_CURSES_H"
./configure --prefix=/usr/local/mysql
This will avoid problems with the `libstdc++' library and with C++
exceptions.
If this doesn't help, you should compile a debug version and run it
with a trace file or under `gdb'. *Note Debugging server::.
SunOS 4 Notes
-------------
On SunOS 4, MIT-pthreads is needed to compile *MySQL*, which in turn
means you will need GNU `make'.
Some SunOS 4 systems have problems with dynamic libraries and
`libtool'. You can use the following `configure' line to avoid this
problem:
shell> ./configure --disable-shared --with-mysqld-ldflags=-all-static
When compiling `readline', you may get warnings about duplicate defines.
These may be ignored.
When compiling `mysqld', there will be some `implicit declaration of
function' warnings. These may be ignored.
Linux Notes (All Linux Versions)
--------------------------------
*MySQL* uses LinuxThreads on Linux. If you are using an old Linux
version that doesn't have `glibc2', you must install LinuxThreads
before trying to compile *MySQL*. `http://www.mysql.com/Downloads/Linux'
Note that `glibc' versions before and including Version 2.1.1 have a
fatal bug in `pthread_mutex_timedwait' handling, which is used when you
do `INSERT DELAYED'. If you are using `INSERT DELAYED', you *MUST* add
the following patch to your glibc library:
`http://www.mysql.com/Downloads/Patches/glibc-pthread_cond_timedwait.patch'.
*MySQL* Versions 3.23.7 and 3.22.32 contain a temporary workaround for
this bug.
If you plan to have 1000+ concurrent connections, you will need to make
some changes to LinuxThreads, recompile it, and relink MySQL against
the new `libpthread.a'. Increase `PTHREAD_THREADS_MAX' in
`sysdeps/unix/sysv/linux/bits/local_lim.h' to 4096 and decrease
`STACK_SIZE' in `linuxthreads/internals.h' to 256 KB. The paths are
relative to the root of `glibc' Note that MySQL will not be stable with
around 600-1000 connections if `STACK_SIZE' is the default of 2 MB.
`STACK_SIZE' constant in *LinuxThreads* controls the spacing of thread
stacks in the address space. It needs to be large enough so that there
will be plenty of room for the stack of each individual thread, but
small enough to keep the stack of some thread from running into the
global `mysqld' data. Unfortunately, Linux implementation of `mmap()',
as we have experimentaly discovered, will successfully unmap an already
mapped region if you ask it to map out an address already in use,
zeroing out the data on the entire page, instead of returning an error.
So the safety of `mysqld' or any other threaded application depends on
the "gentleman" behaviour of the code that creates threads - the user
must take measures to make sure the number of running threads at any
time is sufficiently low for thread stacks to stay away from the global
heap. With `mysqld', you should enforce this "gentleman" behaviour by
setting a reasonable value for `max_connections' variable. If you
build *MySQL* yourself and do not what to mess with patching
*LinuxThreads*, you should set `max_connections' to a value no higher
than 500. It should be even less if you have a large key buffer, large
heap tables, or some other things that make *mysqld* allocate a lot of
memory or if you are running a 2.2 kernel with a 2 GB patch. If you are
using our binary or RPM version 3.23.25 or later, you can safely set
`max_connections' at 1500 again assuming no large key buffer or heap
tables with lots of data. The more you reduce `STACK_SIZE' in
LinuxThreads the more threads you can safely create. We recommend the
values between 128K and 256 K.
If you use a lot of concurrent connections, you may suffer from a 2.2
kernel "feature" in 2.2 kernel that penalizes a process for forking or
cloning a child in an attempt to prevent a fork bomb attack. This will
cause MySQL not to scale well as you increase the number of concurrent
clients. On single CPU systems, we have seen this manifested in a very
slow thread creation - which means it may take a long time to connect
to MySQL (as long as 1 minute), and it may take just as long to shut it
down. On multiple CPU systems, we have observed a gradual drop in query
speed as the number of clients increases. In the process of trying to
find a solution, we have received a kernel patch from one of our users,
who claimed it made a lot of difference for his site. We have done some
limited testing in which the patch greatly improved the scalabitility of
MySQL. The patch is available here
(`http://www.mysql.com/Downloads/Patches/linux-fork.patch'). We have
done a rather extensive testing of this patch - Sasha Pachev has
bravely put it on his development machine, and it now has run without
problems for a year. Eventually, we have felt sufficiently confident
about it that we installed it on several systems of one of our biggest
customers. The patch has signficantly improved `MySQL' performance
without causing any problems. So it should be pretty safe. This issue
has been fixed in the 2.4 kernel.
We have also tested *MySQL* on 2.4 kernel on a 2 CPU machine and found
*MySQL* scales MUCH better - there was virtually no slowdown on query
throughput all the way up to 1000 clients. If your plan to set up a
dedicated Linux SMP machine to run *MySQL* under heavy load, we
recommend that you give 2.4 kernel a try! We are currently trying to
collect some info on how well `MySQL' performs on 2.4 kernel on 4-way
and 8-way systems. If you have access such a system and have done some
benchmarks, please send a mail to <docs@mysql.com> with the results -
we will include them in the manual.
There is another issue that greatly hurts *MySQL* performance,
especially on SMP systems. The current implementation of mutex in
Linuxthreads is also very bad for programs with many threads that only
hold the mutex for a short time. On an SMP system, ironic as it is, if
you link *MySQL* against unmodified *LinuxThreads*, removing processors
from the machine improves *MySQL* performance in many cases. We have
made a patch available for glibc 2.1, linuxthreads-2.1-patch
(http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch) and for
glibc 2.2, linuxthreads-2.2-patch
(http://www.mysql.com/Downloads/Linux/linuxthreads-2.2-patch) to
correct this behaviour. Please note that since there are so many
versions of glibc floating around, the patch may not apply cleanly to
yours, so some manual work may be required.
We recommend that you use the above patched to build a special static
version of `libpthread.a' and use it only for statically linking
against `MySQL'. We know that the patch is safe for `MySQL' and
significantly improves its performance, but we cannot say anything
about other applications. If you link other applications against the
patched version of the library, or build a patched shared version and
install it on your system, you are doing it at your own risk with
regard to other applicatioins that depend on `LinuxThreads'.
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' libraries. There are a
lot of simple workarounds to get *MySQL* to work! The simplest is to
use the binary version of *MySQL* (not the RPM) 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::.
One known problem with the binary distribution is that with older Linux
systems that use `libc' (like RedHat 4.x or Slackware), you will get
some non-fatal problems with hostname resolution. *Note Binary
notes-Linux::.
`myisamchk' hangs with `libc.so.5.3.12'. Upgrading to the newest `libc'
fixes this problem.
When using LinuxThreads you will see a minimum of three processes
running. These are in fact threads. There will be one thread for the
LinuxThreads manager, one thread to handle connections, and one thread
to handle alarms and signals.
Note that the linux kernel and the linuxthread library can by default
only have 1024 threads. This means that you can only have up to 1021
connections to MySQL on a unpatched system. The page
`http://www.volano.com/linuxnotes.html' contains information how to go
around this limit.
If you see a dead `mysqld' daemon process with `ps', this usually means
that you have found a bug in *MySQL* or you have a corrupted table.
*Note Crashing::.
To get a core dump on Linux if mysqld dies with a SIGSEGV signal, you
can start mysqld with the `--core-file' option. Note that you also
probably need to raise the `core file size' by adding `ulimit -c
1000000' to `safe_mysqld' or starting `safe_mysqld' with
`--core-file-sizes=1000000'. *Note safe_mysqld::.
If you are using LinuxThreads and `mysqladmin shutdown' doesn't work,
you must upgrade to LinuxThreads Version 0.7.1 or newer.
If you are using RedHat, you might get errors like this:
/usr/bin/perl is needed...
/usr/sh is needed...
/usr/sh is needed...
If so, you should upgrade your version of `rpm' to
`rpm-2.4.11-1.i386.rpm' and `rpm-devel-2.4.11-1.i386.rpm' (or later).
You can get the upgrades of libraries to RedHat Version 4.2 from
`ftp://ftp.redhat.com/updates/4.2/i386'. Or
`http://www.sunsite.unc.edu/pub/Linux/distributions/redhat/code/rpm/'
for other distributions.
If you are linking your own *MySQL* client and get the error:
ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory
When executing them, the problem can be avoided by one of the following
methods:
* Link the client with the following flag (instead of `-Lpath'):
`-Wl,r/path-libmysqlclient.so'.
* Copy `libmysqclient.so' to `/usr/lib'.
* Add the pathname of the directory where `libmysqlclient.so' is
located to the `LD_RUN_PATH' environment variable before running
your client.
If you are using the Fujitsu compiler `(fcc / FCC)' you will have some
problems compiling *MySQL* because the Linux header files are very
`gcc' oriented.
The following `configure' line should work with `fcc/FCC':
CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE -DCONST=const -DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="-O -K fast -K lib -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO '-D_EXTERN_INLINE=static __inline'" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared --with-low-memory
Linux-x86 Notes
...............
*MySQL* requires `libc' Version 5.4.12 or newer. It's known to work
with `libc' 5.4.46. `glibc' Version 2.0.6 and later should also work.
There have been some problems with the `glibc' RPMs from RedHat, so if
you have problems, check whether or not there are any updates! The
`glibc' 2.0.7-19 and 2.0.7-29 RPMs are known to work.
On some older Linux distributions, `configure' may produce an error
like this:
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 message says and add an extra underscore to the
`_P' macro that has only one underscore, then try again.
You may get some warnings when compiling; those shown below 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'
In Debian GNU/Linux, if you want *MySQL* to start automatically when
the system boots, do the following:
shell> cp support-files/mysql.server /etc/init.d/mysql.server
shell> /usr/sbin/update-rc.d mysql.server defaults 99
`mysql.server' can be found in the `share/mysql' directory under the
*MySQL* installation directory or in the `support-files' directory of
the *MySQL* source tree.
If `mysqld' always core dumps when it starts up, the problem may be that
you have an old `/lib/libc.a'. Try renaming it, then remove
`sql/mysqld' and do a new `make install' and try again. This problem
has been reported on some Slackware installations. RedHat Version 5.0
also has a similar problem with some new `glibc' versions. *Note
Linux-RedHat50::.
If you get the following error when linking `mysqld', it means that
your `libg++.a' is not installed correctly:
/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'
You can avoid using `libg++.a' by running `configure' like this:
shell> CXX=gcc ./configure
RedHat Version 5.0 Notes
........................
If you have any problems with *MySQL* on RedHat, you should start by
upgrading `glibc' to the newest possible version!
If you install all the official RedHat patches (including
`glibc-2.0.7-19' and `glibc-devel-2.0.7-19'), both the binary and
source distributions of *MySQL* should work without any trouble!
The updates are needed because 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 a statically linked *MySQL* binary distribution. If you want to
compile from source, you must install the corrected version of
LinuxThreads from `http://www.mysql.com/Downloads/Linux' or upgrade your
`glibc'.
If you have an incorrect version of `glibc' or LinuxThreads, the symptom
is that `mysqld' crashes after each connection. For example,
`mysqladmin version' will crash `mysqld' when it finishes!
Another symptom of incorrect libraries is that `mysqld' crashes at once
when it starts. On some Linux systems, this can be fixed by configuring
like this:
shell> ./configure --with-mysqld-ldflags=-all-static
On Redhat Version 5.0, the easy way out is to install the `glibc'
2.0.7-19 RPM and run `configure' *without* the
`--with-mysqld-ldflags=-all-static' option.
For the source distribution of `glibc' 2.0.7, a patch that is easy to
apply and is tested with *MySQL* may be found at:
`http://www.mysql.com/Download/Linux/glibc-2.0.7-total-patch.tar.gz'
If you experience crashes like these when you build *MySQL*, you can
always download the newest binary version of *MySQL*. This is
statically-linked to avoid library conflicts and should work on all
Linux systems!
*MySQL* comes with an internal debugger that can generate trace files
with a lot of information that can be used to find and solve a wide
range of different problems. *Note Debugging server::.
RedHat Version 5.1 notes
........................
The `glibc' of RedHat Version 5.1 (`glibc' 2.0.7-13) has a memory leak,
so to get a stable *MySQL* version, you must upgrade `glibc', to
2.0.7-19, downgrade `glibc' or use a binary version of `mysqld'. If
you don't do this, you will encounter memory problems (out of memory,
etc.). The most common error in this case is:
Can't create a new thread (errno 11). If you are not out of available
memory, you can consult the manual for any possible OS dependent bug
After you have upgraded to `glibc' 2.0.7-19, you can configure *MySQL*
with dynamic linking (the default), but you *cannot* run `configure'
with the `--with-mysqld-ldflags=-all-static' option until you have
installed `glibc' 2.0.7-19 from source!
You can check which version of `glibc' you have with `rpm -q glibc'.
Another reason for the above error is if you try to use more threads
than your Linux kernel is configured for. In this case you should raise
the limits in `include/linux/tasks.h' and recompile your kernel!
Linux-SPARC Notes
.................
In some implementations, `readdir_r()' is broken. The symptom is that
`SHOW DATABASES' always returns an empty set. This can be fixed by
removing `HAVE_READDIR_R' from `config.h' after configuring and before
compiling.
Some problems will require patching your Linux installation. The patch
can be found at
`http://www.mysql.com/Downloads/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' (a version of Linux that was never
merged with the official 2.0.30). You must also install LinuxThreads
Version 0.6 or newer.
Linux-Alpha Notes
.................
*MySQL* Version 3.23.12 is the first *MySQL* version that is tested on
Linux-Alpha. If you plan to use *MySQL* on Linux-Alpha, you should
ensure that you have this version or newer.
We have tested *MySQL* on Alpha with our benchmarks + test suite and it
appears to work nicely. The main thing we haven't yet had time to test
is how things works with many concurrent users.
When we compiled the standard *MySQL* binary we are using SuSE 6.4,
kernel 2.2.13-SMP, Compaq C compiler (V6.2-504) and Compaq C++ compiler
(V6.3-005) on a Comaq DS20 machine with an Alpha EV6 processor
You can find the above compilers at
`http://www.support.compaq.com/alpha-tools'). By using these compilers,
instead of gcc, we get about 9-14 % better performance with *MySQL*.
Note that the configure line optimized the binary for the current CPU;
This means you can only use our binary if you have an Alpha EV6
processor. We also compile staticly to avoid library problems.
CC=ccc CFLAGS="-fast" CXX=cxx CXXFLAGS="-fast -noexceptions -nortti" ./configure --prefix=/usr/local/mysql --disable-shared --with-extra-charsets=complex --enable-thread-safe-client --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared
If you want to use egcs the following configure line worked for us:
CFLAGS="-O6 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --disable-shared
Some known problems when running *MySQL* on Linux-Alpha:
* Debugging threaded applications like *MySQL* will not work with
`gdb 4.18'. You should download and use gdb 5.0 instead!
* If you try linking mysqld staticly when using gcc, the resulting
image will core dump at start. In other words, *DON'T* use
`--with-mysqld-ldflags=-all-static' with gcc
MkLinux Notes
.............
*MySQL* should work on MkLinux with the newest `glibc' package (tested
with `glibc' 2.0.7).
Qube2 Linux Notes
.................
To get *MySQL* to work on Qube2, (Linux Mips), you need the newest
`glibc' libraries (`glibc-2.0.7-29C2' is known to work). You must also
use the `egcs' C++ compiler (`egcs-1.0.2-9', `gcc 2.95.2' or newer).
Linux IA64 Notes
................
To get *MySQL* to compile on Linux Ia64, we had to do the following (we
assume that this will be easier when next gcc version for ia64 is
released).
Using `gcc-2.9-final':
CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared --with-extra-charsets=complex
After `make' you will get an error that `sql/opt_range.cc' will not
compile (internal compiler error). To fix this, go to the sql directory
and type `make' again. Copy the compile line, but change -O2 to -O0.
The file should now compile.
Now you can do:
cd ..
make
make_install
and *mysqld* should be ready to run.
Alpha-DEC-UNIX Notes (Tru64)
----------------------------
If you are using egcs 1.1.2 on Digital Unix, you should upgrade to gcc
2.95.2, as egcs on DEC has some serious bugs!
When compiling threaded programs under Digital Unix, the documentation
recommends using the `-pthread' option for `cc' and `cxx' and the
libraries `-lmach -lexc' (in addition to `-lpthread'). You should run
`configure' something like this:
CC="cc -pthread" CXX="cxx -pthread -O"
./configure --with-named-thread-libs="-lpthread -lmach -lexc -lc"
When compiling `mysqld', you may see a couple of warnings like this:
mysqld.cc: In function void handle_connections()':
mysqld.cc:626: passing long unsigned int *' as argument 3 of
accept(int,sockadddr *, int *)'
You can safely ignore these warnings. They occur because `configure'
can detect only errors, not warnings.
If you start the server directly from the command line, you may have
problems with it dying when you log out. (When you log out, your
outstanding processes receive a `SIGHUP' signal.) If so, try starting
the server like this:
shell> nohup mysqld [options] &
`nohup' causes the command following it to ignore any `SIGHUP' signal
sent from the terminal. Alternatively, start the server by running
`safe_mysqld', which invokes `mysqld' using `nohup' for you. *Note
safe_mysqld::.
If you get a problem when compiling mysys/get_opt.c, just remove the
line #define _NO_PROTO from the start of that file!
If you are using Compac's CC compiler, the following configure line
should work:
CC="cc -pthread"
CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all -arch host"
CXX="cxx -pthread"
CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all -arch host"
export CC CFLAGS CXX CXXFLAGS
./configure
--prefix=/usr/local/mysql
--with-low-memory
--enable-large-files
--enable-shared=yes
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
gnumake
If you get a problem with libtool, when compiling with shared libraries
as above, when linking `mysql', you should be able to get around this
by issuing:
cd mysql
/bin/sh ../libtool --mode=link cxx -pthread -O3 -DDBUG_OFF
-O4 -ansi_alias -ansi_args -fast -inline speed
-speculate all -arch host -DUNDEF_HAVE_GETHOSTBYNAME_R
-o mysql mysql.o readline.o sql_string.o completion_hash.o
../readline/libreadline.a -lcurses
../libmysql/.libs/libmysqlclient.so -lm
cd ..
gnumake
gnumake install
scripts/mysql_install_db
Alpha-DEC-OSF1 Notes
--------------------
If you have problems compiling and have DEC `CC' and `gcc' installed,
try running `configure' like this:
CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3
./configure --prefix=/usr/local/mysql
If you get problems with the `c_asm.h' file, you can create and use a
'dummy' `c_asm.h' file with:
touch include/c_asm.h
CC=gcc CFLAGS=-I./include
CXX=gcc CXXFLAGS=-O3
./configure --prefix=/usr/local/mysql
Note that the following problems with the `ld' program can be fixed by
downloading the latest DEC (Compaq) patch kit from:
`http://ftp.support.compaq.com/public/unix/'.
On OSF1 V4.0D and compiler "DEC C V5.6-071 on Digital Unix V4.0 (Rev.
878)" the compiler had some strange behavior (undefined `asm' symbols).
`/bin/ld' also appears to be broken (problems with `_exit undefined'
errors occuring while linking `mysqld'). On this system, we have
managed to compile *MySQL* with the following `configure' line, after
replacing `/bin/ld' with the version from OSF 4.0C:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
With the Digital compiler "C++ V6.1-029", the following should work:
CC=cc -pthread
CFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all -arch host
CXX=cxx -pthread
CXXFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all -arch host -noexceptions -nortti
export CC CFLAGS CXX CXXFLAGS
./configure --prefix=/usr/mysql/mysql --with-mysqld-ldflags=-all-static --disable-shared --with-named-thread-libs="-lmach -lexc -lc"
In some versions of OSF1, the `alloca()' function is broken. Fix this
by removing the line in `config.h' that defines `'HAVE_ALLOCA''.
The `alloca()' function also may have an incorrect prototype in
`/usr/include/alloca.h'. This warning resulting from this can be
ignored.
`configure' will use the following thread libraries automatically:
`--with-named-thread-libs="-lpthread -lmach -lexc -lc"'.
When using `gcc', you can also try running `configure' like this:
shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ....
If you have problems with signals (*MySQL* dies unexpectedly under high
load), you may have found an OS bug with threads and signals. In this
case you can tell *MySQL* not to use signals by configuring with:
shell> CFLAGS=-DDONT_USE_THR_ALARM
CXXFLAGS=-DDONT_USE_THR_ALARM
./configure ...
This doesn't affect the performance of *MySQL*, but has the side effect
that you can't kill clients that are "sleeping" on a connection with
`mysqladmin kill' or `mysqladmin shutdown'. Instead, the client will
die when it issues its next command.
With `gcc' 2.95.2, you will probably run into the following compile
error:
sql_acl.cc:1456: Internal compiler error in `scan_region', at except.c:2566
Please submit a full bug report.
To fix this you should change to the `sql' directory and do a "cut and
paste" of the last `gcc' line, but change `-O3' to `-O0' (or add `-O0'
immediately after `gcc' if you don't have any `-O' option on your
compile line.) After this is done you can just change back to the
top-level directly and run `make' again.
SGI-Irix Notes
--------------
If you are using Irix Version 6.5.3 or newer `mysqld' will only be able
to create threads if you run it as a user with `CAP_SCHED_MGT'
privileges (like `root') or give the `mysqld' server this privilege
with the following shell command:
shell> chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld
You may have to undefine some things in `config.h' after running
`configure' and before compiling.
In some Irix implementations, the `alloca()' function is broken. If the
`mysqld' server dies on some `SELECT' statements, remove the lines from
`config.h' that define `HAVE_ALLOC' and `HAVE_ALLOCA_H'. If
`mysqladmin create' doesn't work, remove the line from `config.h' that
defines `HAVE_READDIR_R'. You may have to remove the `HAVE_TERM_H' line
as well.
SGI recommends that you install all of the patches on this page as a
set:
http://support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html
At the very minimum, you should install the latest kernel rollup, the
latest `rld' rollup, and the latest `libc' rollup.
You definately need all the POSIX patches on this page, for pthreads
support:
http://support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html
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
then type the following in the top-level directory of your *MySQL*
source tree:
shell> extra/replace bool curses_bool < /usr/include/curses.h > include/curses.h
shell> make
There have also been reports of scheduling problems. If only one
thread is running, things go slow. Avoid this by starting another
client. This may lead to a 2-to-10-fold increase in execution speed
thereafter for the other thread. This is a poorly understood problem
with Irix threads; 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'
command:
CC=gcc CXX=gcc CXXFLAGS=-O3
./configure --prefix=/usr/local/mysql --with-thread-safe-client --with-named-thread-libs=-lpthread
FreeBSD Notes
-------------
FreeBSD 3.x is recommended for running *MySQL* since the thread package
is much more integrated.
The easiest and therefor the preferred way to install is to use the
mysql-server and mysql-client ports available on
`http://www.freebsd.org'.
Using these gives you:
* A working *MySQL* with all optimizations known to work on your
version of FreeBSD enabled.
* Automatic configuration and build.
* Startup scripts installed in /usr/local/etc/rc.d.
* Ability to see which files that are installed with pkg_info -L.
And to remove them all with pkg_delete if you no longer want
*MySQL* on that machine.
It is recomended you use MIT-pthreads on FreeBSD 2.x and native threads
on Versions 3 and up. It is possible to run with native threads on
some late 2.2.x versions but you may encounter problems shutting down
mysqld.
The *MYSQL* Makefiles require GNU make (`gmake') to work. If you want
to compile *MYSQL* you need to install GNU make first.
Be sure to have your name resolver setup correct. Otherwise you may
experience resolver delays or failures when connecting to mysqld.
Make sure that the `localhost' entry in the `/etc/hosts' file is
correct (otherwise you will have problems connecting to the database).
The `/etc/hosts' file should start with a line:
127.0.0.1 localhost localhost.your.domain
If you notice that `configure' will use MIT-pthreads, you should read
the MIT-pthreads notes. *Note MIT-pthreads::.
If you get an error from `make install' that it can't find
`/usr/include/pthreads', `configure' didn't detect that you need
MIT-pthreads. This is fixed by executing these commands:
shell> rm config.cache
shell> ./configure --with-mit-threads
FreeBSD is also known to have a very low default file handle limit.
*Note Not enough file handles::. Uncomment the ulimit -n section in
safe_mysqld or raise the limits for the mysqld user in /etc/login.conf
(and rebuild it witg cap_mkdb /etc/login.conf.) Also be sure you set the
appropriate class for this user in the password file if you are not
using the default (use: chpass mysqld-user-name). *Note safe_mysqld::.
If you get problems with the current date in *MySQL*, setting the `TZ'
variable will probably help. *Note Environment variables::.
To get a secure and stable system you should only use FreeBSD kernels
that are marked `-STABLE'
NetBSD notes
------------
To compile on NetBSD you need GNU `make'. Otherwise the compile will
crash when `make' tries to run `lint' on C++ files.
OpenBSD Notes
-------------
OpenBSD 2.5 Notes
.................
On OpenBSD Version 2.5, you can compile *MySQL* with native threads
with the following options:
CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no
OpenBSD 2.8 Notes
.................
Our users have reported that OpenBSD 2.8 has a threading bug which
causes problems with MySQL. The OpenBSD Developers have fixed the
problem, but as of January 25th, 2001, it's only available in the
"-current" branch. The symptoms of this threading bug are: slow
response, high load, high cpu usage, and crashes.
BSD/OS Notes
------------
BSD/OS Version 2.x Notes
........................
If you get the following error when compiling *MySQL*, your `ulimit'
value for virtual memory is too low:
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
Try using `ulimit -v 80000' and run `make' again. If this doesn't work
and you are using `bash', try switching to `csh' or `sh'; some BSDI
users have reported problems with `bash' and `ulimit'.
If you are using `gcc', you may also use have to use the
`--with-low-memory' flag for `configure' to be able to compile
`sql_yacc.cc'.
If you get problems with the current date in *MySQL*, setting the `TZ'
variable will probably help. *Note Environment variables::.
BSD/OS Version 3.x Notes
........................
Upgrade to BSD/OS Version 3.1. If that is not possible, install
BSDIpatch M300-038.
Use the following command when configuring *MySQL*:
shell> 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:
shell> env CC=gcc CXX=gcc CXXFLAGS=-O3
./configure
--prefix=/usr/local/mysql
--with-unix-socket-path=/var/mysql/mysql.sock
You can change the directory locations if you wish, or just use the
defaults by not specifying any locations.
If you have problems with performance under heavy load, try using the
`--skip-thread-priority' option to `mysqld'! This will run all threads
with the same priority; on BSDI Version 3.1, this gives better
performance (at least until BSDI fixes their thread scheduler).
If you get the error `virtual memory exhausted' while compiling, you
should try using `ulimit -v 80000' and run `make' again. If this
doesn't work and you are using `bash', try switching to `csh' or `sh';
some BSDI users have reported problems with `bash' and `ulimit'.
BSD/OS Version 4.x Notes
........................
BSDI Version 4.x has some thread-related bugs. If you want to use
*MySQL* on this, you should install all thread-related patches. At least
M400-023 should be installed.
On some BSDI Version 4.x systems, you may get problems with shared
libraries. The symptom is that you can't execute any client programs,
for example, `mysqladmin'. In this case you need to reconfigure not to
use shared libraries with the `--disable-shared' option to configure.
Some customers have had problems on BSDI 4.0.1 that the `mysqld' binary
after a while can't open tables. This is because some library/system
related bug causes `mysqld' to change current directory without asking
for this!
The fix is to either upgrade to 3.23.34 or after running `configure'
remove the line `#define HAVE_REALPATH' from `config.h' before running
make.
Note that the above means that you can't symbolic link a database
directories to another database directory or symbolic link a table to
another database on BSDI! (Making a symbolic link to another disk is
ok).
SCO Notes
---------
The current port is tested only on a "sco3.2v5.0.4" and "sco3.2v5.0.5"
system. There has also been a lot of progress on a port to "sco
3.2v4.2".
For the moment the recommended compiler on OpenServer is gcc 2.95.2.
With this you should be able to compile *MySQL* with just:
CC=gcc CXX=gcc ./configure ... (options)
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'. You can also use `egcs' 1.1.2 or newer
`http://www.egcs.com/'. If you are using `egcs' 1.1.2 you have to
execute the following command:
shell> cp -p /usr/include/pthread/stdtypes.h /usr/local/lib/gcc-lib/i386-pc-sco3.2v5.0.5/egcs-2.91.66/include/pthread/
2. You need the port of GCC 2.5.x for this product and the Development
system. They are required on this version of SCO Unix. You cannot
just use the GCC Dev system.
3. You should get the FSU Pthreads package and install it 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
`http://www.mysql.com/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
Development 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.x There are a lot of
problems without a good port. The port for this product requires
the SCO Unix Development system. Without it, you are missing the
libraries and the linker that is needed.
5. To build FSU Pthreads on your system, do the following:
a. Run `./configure' in the `threads/src' directory and select
the SCO OpenServer option. This command copies
`Makefile.SCO5' to `Makefile'.
b. Run `make'.
c. To install in the default `/usr/include' directory, login as
root, then `cd' to the `thread/src' directory, and run `make
install'.
6. Remember to use GNU `make' when making *MySQL*.
7. If you don't start `safe_mysqld' as root, you probably will get
only the default 110 open files per process. `mysqld' will write
a note about this in the log file.
8. With SCO 3.2V5.0.5, you should use FSU Pthreads version 3.5c or
newer. You should also use gcc 2.95.2 or newer!
The following `configure' command should work:
shell> ./configure --prefix=/usr/local/mysql --disable-shared
9. With SCO 3.2V4.2, you should use FSU Pthreads version 3.5c or
newer. The following `configure' command should work:
shell> CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4"
./configure
--with-debug --prefix=/usr/local/mysql
--with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads"
--with-named-curses-libs="-lcurses"
You may get some problems with some include files. In this case,
you can find new SCO-specific include files at
`http://www.mysql.com/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz'.
You should unpack this file in the `include' directory of your
*MySQL* source tree.
SCO development notes:
* *MySQL* should automatically detect FSU Pthreads and link `mysqld'
with `-lgthreads -lsocket -lgthreads'.
* The SCO development libraries are re-entrant in FSU Pthreads. SCO
claims that its libraries' functions are re-entrant, so they must
be reentrant with FSU Pthreads. FSU Pthreads on OpenServer tries
to use the SCO scheme to make re-entrant libraries.
* FSU Pthreads (at least the version at `http://www.mysql.com/')
comes linked with GNU `malloc'. If you encounter problems with
memory usage, make sure that `gmalloc.o' is included in
`libgthreads.a' and `libgthreads.so'.
* In FSU Pthreads, the following system calls are pthreads-aware:
`read()', `write()', `getmsg()', `connect()', `accept()',
`select()', and `wait()'.
If you want to install DBI on SCO, you have to edit the `Makefile' in
DBI-xxx and each subdirectory.
Note that the following assumes gcc 2.95.2 or newer:
OLD: NEW:
CC = cc CC = gcc
CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic
CCDLFLAGS = -wl,-Bexport CCDLFLAGS =
LD = ld LD = gcc -G -fpic
LDDLFLAGS = -G -L/usr/local/lib LDDLFLAGS = -L/usr/local/lib
LDFLAGS = -belf -L/usr/local/lib LDFLAGS = -L/usr/local/lib
LD = ld LD = gcc -G -fpic
OPTIMISE = -Od OPTIMISE = -O1
OLD:
CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include
NEW:
CCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include
This is because the Perl dynaloader will not load the `DBI' modules if
they were compiled with `icc' or `cc'.
Perl works best when compiled with `cc'.
SCO Unixware Version 7.0 Notes
------------------------------
You must use a version of *MySQL* at least as recent as Version 3.22.13
because that version fixes some portability problems under Unixware.
We have been able to compile *MySQL* with the following `configure'
command on Unixware Version 7.0.1:
CC=cc CXX=CC ./configure --prefix=/usr/local/mysql
If you want to use `gcc', you must use `gcc' 2.95.2 or newer.
IBM-AIX notes
-------------
Automatic detection of `xlC' is missing from Autoconf, so a `configure'
command something like this is needed when compiling *MySQL* (The
example uses the IBM compiler):
export CC="xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 "
export CXX="xlC_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192"
export CFLAGS="-I /usr/local/include"
export LDLFAGS="-L /usr/local/lib"
export CPPFLAGS=$CFLAGS
export CXXFLAGS=$CFLAGS
./configure --prefix=/usr/local
--localstatedir=/var/mysql
--sysconfdir=/etc/mysql
--sbindir='/usr/local/bin'
--libexecdir='/usr/local/bin'
--enable-thread-safe-client
--enable-large-files
Above are the options used to compile the *MySQL* distribution that can
be found at www-frec.bull.com (http://www-frec.bull.com/).
If you change the `-O3' to `-O2' in the above configure line, you must
also remove the `-qstrict' option (this is a limitation in the IBM C
compiler).
If you are using `gcc' or `egcs' to compile *MySQL*, you *MUST* use the
`-fno-exceptions' flag, as the exception handling in `gcc'/`egcs' is
not thread safe! (This is tested with `egcs' 1.1.). There are also
some known problems with IBM's assembler, which may cause it to
generate bad code when used with gcc.
We recommend the following `configure' line with `egcs' and `gcc 2.95'
on AIX:
CC="gcc -pipe -mcpu=power2 -Wa,-many"
CXX="gcc -pipe -mcpu=power2 -Wa,-many"
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --with-low-memory
The `-Wa,-many' is necessary for the compile to be successful. IBM is
aware of this problem but is in to hurry to fix it because of the
workaround available. We don't know if the `-fno-exceptions' is
required with `gcc 2.95', but as *MySQL* doesn't use exceptions and the
above option generates faster code, we recommend that you should always
use this option with `egcs / gcc'.
If you have problems with signals (*MySQL* dies unexpectedly under high
load) you may have found an OS bug with threads and signals. In this
case you can tell *MySQL* not to use signals by configuring with:
shell> CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -DDONT_USE_THR_ALARM"
./configure --prefix=/usr/local/mysql --with-debug --with-low-memory
This doesn't affect the performance of *MySQL*, but has the side effect
that you can't kill clients that are "sleeping" on a connection with
`mysqladmin kill' or `mysqladmin shutdown'. Instead, the client will
die when it issues its next command.
On some versions of AIX, linking with `libbind.a' makes `getservbyname'
core dump. This is an AIX bug and should be reported to IBM.
HP-UX Version 10.20 Notes
-------------------------
There are a couple of small problems when compiling *MySQL* on HP-UX.
We recommend that you use `gcc' instead of the HP-UX native compiler,
because `gcc' produces better code!
We recommend using gcc 2.95 on HP-UX. Don't use high optimization
flags (like -O6) as this may not be safe on HP-UX.
Note that MIT-pthreads can't be compiled with the HP-UX compiler
because it can't compile `.S' (assembler) files.
The following configure line should work:
CFLAGS="-DHPUX -I/opt/dce/include" CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors -fno-exceptions -fno-rtti" CXX=gcc ./configure --with-pthread --with-named-thread-libs='-ldce' --prefix=/usr/local/mysql --disable-shared
If you are compiling `gcc' 2.95 yourself, you should NOT link it with
the DCE libraries (`libdce.a' or `libcma.a') if you want to compile
*MySQL* with MIT-pthreads. If you mix the DCE and MIT-pthreads
packages you will get a `mysqld' to which you cannot connect. Remove
the DCE libraries while you compile `gcc' 2.95!
HP-UX Version 11.x Notes
------------------------
For HPUX Version 11.x we recommend *MySQL* Version 3.23.15 or later.
Because of some critical bugs in the standard HPUX libraries, one should
install the following patches before trying to run MySQL on HPUX 11.0:
PHKL_22840 Streams cumulative
PHNE_22397 ARPA cumulative
This will solve a problem that one gets `EWOULDBLOCK' from `recv()' and
`EBADF' from `accept()' in threaded applications.
If you are using `gcc' 2.95.1 on a unpatched HPUX 11.x system, you will
get the error:
In file included from /usr/include/unistd.h:11,
from ../include/global.h:125,
from mysql_priv.h:15,
from item.cc:19:
/usr/include/sys/unistd.h:184: declaration of C function ...
/usr/include/sys/pthread.h:440: previous declaration ...
In file included from item.h:306,
from mysql_priv.h:158,
from item.cc:19:
The problem is that HP-UX doesn't define `pthreads_atfork()'
consistently. It has conflicting prototypes in
`/usr/include/sys/unistd.h':184 and `/usr/include/sys/pthread.h':440 (I
post the details below).
One solution is to copy `/usr/include/sys/unistd.h' into
`mysql/include' and edit `unistd.h' and change it to match the
definition in `pthread.h'. Here's the diff:
183,184c183,184
< extern int pthread_atfork(void (*prepare)(), void (*parent)(),
< void (*child)());
---
> extern int pthread_atfork(void (*prepare)(void), void (*parent)(void),
> void (*child)(void));
After this, the following configure line should work:
CFLAGS="-fomit-frame-pointer -O6 -fpic" CXX=gcc CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O6" ./configure --prefix=/usr/local/mysql --disable-shared
Here is some information that a HPUX Version 11.x user sent us about
compiling *MySQL* with HPUX:x compiler:
Environment:
proper compilers.
setenv CC cc
setenv CXX aCC
flags
setenv CFLAGS -D_REENTRANT
setenv CXXFLAGS -D_REENTRANT
setenv CPPFLAGS -D_REENTRANT
% aCC -V
aCC: HP ANSI C++ B3910B X.03.14.06
% cc -V /tmp/empty.c
cpp.ansi: HP92453-01 A.11.02.00 HP C Preprocessor (ANSI)
ccom: HP92453-01 A.11.01.00 HP C Compiler
cc: "/tmp/empty.c", line 1: warning 501: Empty source file.
configuration:
./configure --with-pthread
--prefix=/source-control/mysql
--with-named-thread-libs=-lpthread
--with-low-memory
added '#define _CTYPE_INCLUDED' to include/m_ctype.h. This
symbol is the one defined in HP's /usr/include/ctype.h:
/* Don't include std ctype.h when this is included */
#define _CTYPE_H
#define __CTYPE_INCLUDED
#define _CTYPE_INCLUDED
#define _CTYPE_USING /* Don't put names in global namespace. */
* I had to use the compile-time flag `-D_REENTRANT' to get the
compiler to recognize the prototype for `localtime_r'.
Alternatively I could have supplied the prototype for
`localtime_r'. But I wanted to catch other bugs without needing to
run into them. I wasn't sure where I needed it, so I added it to
all flags.
* The optimization flags used by *MySQL* (-O3) are not recognized by
HP's compilers. I did not change the flags.
Mac OS X Notes
--------------
Mac OS X Public beta
....................
*MySQL* should work without any probelms on Mac OS X public beta.
(Darwin); You don't need the pthread patches for this os!
Mac OS X Server
...............
Before trying to configure *MySQL* on Mac OS X server you must first
first install the pthread package from
`http://www.prnet.de/RegEx/mysql.html'. Note that this is not neeaded
Our binary for Mac OS X is compiled on Rhapsody 5.5 with the following
configure line:
CC=gcc CFLAGS="-O2 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O2 -fomit-frame-pointer" ./configure --prefix=/usr/local/mysql "--with-comment=Official MySQL binary" --with-extra-charsets=complex --disable-shared
You might want to also add aliases to your shell's resource file to
access `mysql' and `mysqladmin' from the command line:
alias mysql '/usr/local/mysql/bin/mysql'
alias mysqladmin '/usr/local/mysql/bin/mysqladmin'
BeOS Notes
----------
We are really interested in getting *MySQL* to work on BeOS, but
unfortunately we don't have any person who knows BeOS or has time to do
a port.