La detección automática de xlC no se encuentra presente en Autoconf, de modo que habrá que inicializar una cantidad de variables antes de ejecutar configure. El siguiente ejemplo utiliza el compilador de IBM:

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

Estas opciones se emplean para compilar la distribución MySQL que se encuentra en http://www-frec.bull.com/.

Si se cambia el -O3 por -O2 en la linea de configure anterior, también habrá que quitar la opción -qstrict. Esto es una limitación en el compilador de C de IBM.

Si se está empleando gcc o egcs para compilar MySQL, se debe utilizar el flag -fno-exceptions, porque la gestión de excepciones en gcc/egcs no es apta para subprocesos. (Esto se probó con egcs 1.1.) También hay algunos problemas conocidos con el ensamblador de IBM, el cual puede generar código defectuoso cuando se lo usa con gcc.

Se recomienda usar la siguiente línea de configure con egcs y gcc 2.95 en 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

La opción -Wa,-many se necesita para que el proceso de compilación tenga éxito. IBM está al tanto de este problema pero no tiene urgencia por resolverlo porque hay disponible una solución alternativa. No se sabe si -fno-exceptions se requiere con gcc 2.95, pero como MySQL no utiliza excepciones y la opción genera código más rápido, se recomienda usarlo siempre con egcs / gcc.

Si se obtiene un problema con el código ensamblador, hay que cambiar la opción -mcpu=xxx para que concuerde con la CPU del usuario. Generalmente puede necesitarse power2, power, o powerpc. O bien podría necesitarse 604 o 604e. No está confirmado, pero se sospecha que power puede muy bien ser seguro la mayoría de las veces, incluso en un ordenador de 2 procesadores.

Si se desconoce el tipo de CPU que se posee, ejecutar un comando uname -m. Este produce una cadena con un aspecto similar a 000514676700, con el formato xxyyyyyymmss, donde xx y ss son siempre 00, yyyyyy es un identificador único de sistema, y mm es el identificar de la arquitectura de la CPU. La tabla con estos valores se encuentra en http://www16.boulder.ibm.com/pseries/en_US/cmds/aixcmds5/uname.htm.

Esto proporciona el tipo y modelo del ordenador que se está usando.

Si se tienen problemas con señales (MySQL termina abruptamente al someterlo a carga intensiva), puede tratarse de un error del SO relacionado con subprocesos y señales. En este caso, hay que indicarle a MySQL que no utilice señales, configurándolo como sigue:

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

Esto no afecta el rendimiento de MySQL, pero tiene el efecto secundario de que no se pueden terminar procesos de clientes que están “durmiendo” (“sleeping”) en una conexión usando mysqladmin kill o mysqladmin shutdown. El cliente terminará cuando emita su siguiente comando.

En algunas versiones de AIX, el enlazado con libbind.a provoca que getservbyname() haga un volcado de núcleo. Este es un error en AIX y debería informarse a IBM.

Para AIX 4.2.1 y gcc, se deben hacer los siguientes cambios.

Después de configurar, editar config.h y include/my_config.h y cambiar la línea que dice:

#define HAVE_SNPRINTF 1

a esto:

#undef HAVE_SNPRINTF

Y, finalmente, en mysqld.cc, se necesitará agregar un prototipo para initgroups().

#ifdef _AIX41
extern "C" int initgroups(const char *,int);
#endif

Si se necesita asginar mucha memoria para el proceso mysqld, no basta con utilizar ulimit -d unlimited. También habrá que modificar mysqld_safe agregando una línea como la siguiente:

export LDR_CNTRL='MAXDATA=0x80000000'

Se puede encontrar más información acerca de usar grandes cantidades de memoria en http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm.