MySQL Reference Manual for version 3.23.5-alpha.



	4.11 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. 4.11.1 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 2.4 and earlier versions, MySQL will automatically use MIT-pthreads. 4.9 MIT-pthreads notes. 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 `egcs` 1.1.2 or newer. You can find this at http://egcs.cygnus.com/. Note that `egs` 1.1.1 and `gcc` 2.8.1 don't work reliably on SPARC! The recommended `configure` line when using `egcs` 1.1.2 is: shell> CC=gcc CFLAGS="-O6" \ CXX=gcc CXXFLAGS="-O6 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory If you have the Sun Workshop 4.2 compiler, you can run `configure` like this: CC=cc CFLAGS="-xstrconst -Xa -xO4 -native -mt" CXX=CC CXXFLAGS="-xO4 -native -noex -mt" ./configure --prefix=/usr/local/mysql shell> CC=cc CFLAGS="-Xa -fast -xO4 -native -xstrconst -mt" \ CXX=CC CXXFLAGS="-noex -XO4 -mt" \ ./configure 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 `egcs` 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. 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. 4.11.2 Solaris 2.7 notes You can normally use a Solaris 2.6 binary on Solaris 2.7. Most of the Solaris 2.6 issues also apply for Solaris 2.7. Note that MySQL 3.23.4 and above should be able to autodetect Solaris 2.7 and enable workarounds for the following problems! Solaris 2.7 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 steps: 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. Configure with `CFLAGS=-DHAVE_CURSES CXXFLAGS=-DHAVE_CURSES ./configure` 4.11.3 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: shell> CC=gcc CFLAGS="-O6 -fomit-frame-pointer" \ CXX=gcc \ CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" \ ./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`. G.1 Debugging a MySQL server. 4.11.4 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. 4.11.5 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 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! 10.3 How compiling and linking affects the speed of MySQL. 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 4.6.3.1 Linux notes. `isamchk` 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. If you see a dead `mysqld` daemon process with `ps`, this usually means that you have found a bug in MySQL or you have got a corrupted table. 18.1 What to do if MySQL keeps crashing. If you are using LinuxThreads and `mysqladmin shutdown` doesn't work, you must upgrade to LinuxThreads 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 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 4.11.5.1 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 5.0 has also a similar problem with some new `glibc` versions. 4.11.5.2 RedHat 5.0 notes. 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 4.11.5.2 RedHat 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 since there is a bug in `glibc` 2.0.5 in how `pthread_key_create` variables are freed. With `glibc` 2.0.5, you must use 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 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. G.1 Debugging a MySQL server. 4.11.5.3 RedHat 5.1 notes The `glibc` of RedHat 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., 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`. 4.11.5.4 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/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 0.6 or newer. Thanks to jacques@solucorp.qc.ca for this information. 4.11.5.5 Linux-Alpha notes The big problem on Linux-Alpha is that there are still some problems with threads in `glibc` on this platform. You should start by getting the newest `glibc` version you can find. Note that before you run any programs that use threads (like `mysqld`, `thr_alarm` or `thr_lock`), you should raise the shared memory limit (with `ulimit`). The MySQL benchmarks are known to fail if you forget to do this! Configure MySQL with the following command: shell> CC=gcc CCFLAGS="-Dalpha_linux_port" \ CXX=gcc CXXFLAGS="-O3 -Dalpha_linux_port -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql Try to compile `mysys/thr_lock` and `mysys/thr_alarm`. Test that these programs work! (Invoke each one with no arguments. Each should end with `test_succeeded` if everything was okay.) After installing MySQL, uncomment the `ulimit` command in `safe_mysqld` and add options to increase shared memory. Note that Linux-Alpha is still an alpha-quality platform for MySQL. With the newest `glibc`, you have a very good chance of it working. 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. 4.11.5.6 MkLinux notes MySQL should work on MkLinux with the newest `glibc` package (tested with `glibc` 2.0.7). 4.11.5.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` or newer). 4.11.6 Alpha-DEC-Unix notes 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: shell> 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. 4.11.7 Alpha-DEC-OSF1 notes If you have problems compiling and have DEC `CC` and `gcc` installed, try running `configure` like this: shell> 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: shell> touch include/c_asm.h shell> CC=gcc CFLAGS=-I./include \ CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql On OSF1 V4.0D and compiler "DEC C V5.6-071 on Digital UNIX V4.0 (Rev. 878)" the compiler had some strange 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: shell> CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql 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. 4.11.8 SGI-Irix notes 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: shell> CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql --with-thread-safe-client --with-named-thread-libs=-lpthread 4.11.9 FreeBSD notes 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 to use MIT-pthreads on FreeBSD 2.x and native threads on versions 3 and up. It is possible to run with with native threads on some late 2.2.x versions but you may encounter problems shutting down mysqld. 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. 4.9 MIT-pthreads notes. 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 The behavior of FreeBSD `make` is slightly different from that of GNU `make`. If you have `make`-related problems, you should install GNU `make`. FreeBSD is also known to have a very low default file handle limit. 18.11 File not found. 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) If you have a problem with `SELECT NOW()` returning values in GMT and not your local time, you have to set the `TZ` environment variable to your current timezone. This should be done for the environment in which the server runs, for example, in `safe_mysqld` or `mysql.server`. To get a secure and stable system you should only use FreeBSD kernels that are marked `-STABLE` 4.11.10 NetBSD notes To compile on NetBSD you need GNU `make`. Otherwise the compile will crash when `make` tries to run `lint` on C++ files. 4.11.11 BSD/OS notes 4.11.11.1 BSD/OS 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 have a problem with `SELECT NOW()` returning values in GMT and not your local time, you have to set the `TZ` environment variable to your current timezone. This should be done for the environment in which the server runs, for example in `safe_mysqld` or `mysql.server`. 4.11.11.2 BSD/OS 3.x notes Upgrade to BSD/OS 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 `safe_mysqld`! This will run all threads with the same priority; on BSDI 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`. 4.11.11.3 BSD/OS 4.x notes BSDI 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. 4.11.12 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 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/ You need the port of GCC 2.5.? for this product and the Development system. They are required on this version of SCO UNIX. You cannot just use the GCC Dev system. 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 ftp://www.mysql.com/pub/mysql/Downloads/SCO/FSU-threads-3.5c.tar.gz. 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.? 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. To build FSU Pthreads on your system, do the following: Run `./configure` in the `threads/src' directory and select the SCO OpenServer option. This command copies `Makefile.SCO5' to `Makefile'. Run `make`. To install in the default `/usr/include' directory, login as root, then `cd` to the `thread/src' directory, and run `make install`. Remember to use GNU `make` when making MySQL. On OSR 5.0.5, you should use the following configure line: shell> CC="gcc -DSCO" CXX="gcc -DSCO" ./configure The `-DSCO` is needed to help configure detect some thread functions properly. If you forget `-DSCO`, you will get the following error message while compiling: my_pthread.c: In function `my_pthread_mutex_init': my_pthread.c:374: `pthread_mutexattr_default' undeclared (first use this function) 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. With SCO 3.2V5.0.5, you should use a FSU Pthreads version 3.5c or newer. The following `configure` command should work: shell> CC="gcc -belf" ./configure --prefix=/usr/local/mysql --disable-shared With SCO 3.2V4.2, you should use a 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 ftp://www.mysql.com/pub/mysql/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 reentrant in FSU Pthreads. SCO claims that its libraries' functions are reentrant, so they must be reentrant with FSU Pthreads. FSU Pthreads on OpenServer tries to use the SCO scheme to make reentrant library. FSU Pthreads (at least the version at `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 `Makefiles' in DBI-xxx and each subdirectory: OLD: NEW: CC = cc CC = gcc -belf CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic CCDLFLAGS = -wl,-Bexport CCDLFLAGS = LD = ld LD = gcc -belf -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 -belf -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`. 4.11.13 SCO Unixware 7.0 notes You must use a version of MySQL at least as recent as 3.22.13, since that version fixes some portability problems under Unixware. We have been able to compile MySQL with the following `configure` command on UnixWare 7.0.1: shell> CC=cc CXX=CC ./configure --prefix=/usr/local/mysql 4.11.14 IBM-AIX notes Automatic detection of `xlC` is missing from Autoconf, so a `configure` command something like this is needed when using the IBM compiler: shell> CC="xlc_r -ma -O3 -qstrict -DHAVE_INT_8_16_32" \ CXX="xlC_r -ma -O3 -qstrict -DHAVE_INT_8_16_32" \ ./configure If you are using `egcs` to compile MySQL, you MUST use the `-fno-exceptions` flag, as the exception handling in `egcs` is not thread-safe! (This is tested with `egcs` 1.1.) We recommend the following `configure` line with `egcs` and `gcc` on AIX: shell> CXX=gcc \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/home/monty --with-debug --with-low-memory 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=/home/monty --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. 4.11.15 HP-UX 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 one to use 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!