Automatic detection of
xlC is missing from
Autoconf, so a number of variables need to be set before
running configure. The following 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 LDFLAGS="-L /usr/local/lib" export CPPFLAGS=$CFLAGS export CXXFLAGS=$CFLAGS ./configure --prefix=/usr/local \ --localstatedir=/var/mysql \ --sbindir='/usr/local/bin' \ --libexecdir='/usr/local/bin' \ --enable-thread-safe-client \ --enable-large-files
The preceding options are used to compile the MySQL distribution that can be found at http://www-frec.bull.com/.
If you change the
in the preceding configure line, you must
also remove the
-qstrict option. This is a
limitation in the IBM C compiler.
If you are using gcc to compile MySQL, you
must use the
-fno-exceptions flag, because the exception
handling in gcc is not thread-safe! There
are also some known problems with IBM's assembler that may
cause it to generate bad code when used with
Use the following configure line with gcc 2.95 on AIX:
CC="gcc -pipe -mcpu=power -Wa,-many" \ CXX="gcc -pipe -mcpu=power -Wa,-many" \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory
-Wa,-many option is necessary for the
compile to be successful. IBM is aware of this problem but is
in no hurry to fix it because of the workaround that is
available. We do not know if the
-fno-exceptions is required with
gcc 2.95, but because MySQL does not use
exceptions and the option generates faster code, you should
always use it with gcc.
If you get a problem with assembler code, try changing the
to match your CPU. Typically
need to be used. Alternatively, you might need to use
604e. We are not
positive but suspect that
likely be safe most of the time, even on a power2 machine.
If you do not know which CPU is present, execute a
uname -m command. It produces a string that
000514676700 whose format is
ss are always
yyyyyy is a unique system ID and
mm is the ID of the CPU Planar. A chart of
these values can be found at
This gives you a machine type and model which you can use to determine what type of CPU you have.
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 as follows:
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 does not affect the performance of MySQL, but has the side effect that you cannot kill clients that are “sleeping” on a connection with mysqladmin kill or mysqladmin shutdown. Instead, the client dies when it issues its next command.
On some versions of AIX, linking with
getservbyname() dump core. This is an AIX
bug and should be reported to IBM.
For AIX 4.2.1 and gcc, you have to make the following changes.
After configuring, edit
include/my_config.h and change the line
that says this:
#define HAVE_SNPRINTF 1
And finally, in
mysqld.cc, you need to
add a prototype for
#ifdef _AIX41 extern "C" int initgroups(const char *,int); #endif
For 32-bit binaries, if you need to allocate a lot of memory to the mysqld process, it is not sufficient merely to use ulimit -d unlimited. You may also have to modify mysqld_safe, adding a line something like this:
You can find more information about using very large amounts of memory at http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm.
Users of AIX 4.3 should use gmake instead of the make utility included with AIX.