2.6 Operating SystemSpecific Notes

2.6 Operating System “Specific Notes

2.6.1 Linux Notes

This section discusses issues that have been found to occur on Linux. The first few subsections describe general operating system- related issues, problems that can occur when using binary or source distributions, and post-installation issues. The remaining subsections discuss problems that occur with Linux on specific platforms.

Note that most of these problems occur on older versions of Linux. If you are running a recent version, you likely will see none of them.

2.6.1.1 Linux Operating System Notes

MySQL needs at least Linux Version 2.0.

Warning: We have seen some strange problems with Linux 2.2.14 and MySQL on SMP systems. We also have reports from some MySQL users that they have encountered serious stability problems using MySQL with kernel 2.2.14. If you are using this kernel, you should upgrade to 2.2.19 (or newer ) or to a 2.4 kernel. If you have a multiple-CPU box, then you should seriously consider using 2.4 because it will give you a significant speed boost. Your system also will be more stable.

When using LinuxThreads, you will see a minimum of three mysqld 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.

2.6.1.2 Linux Binary Distribution Notes

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.

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 larger than a dynamically linked program, but also slightly faster (3-5%). However, one problem with a statically linked program is that you can't use user -defined functions (UDFs). If you are going to write or use UDFs (this is something for C or C++ programmers only), you must compile MySQL yourself using dynamic linking.

A known issue with binary distributions is that on older Linux systems that use libc (such as Red Hat 4.x or Slackware), you will get some non-fatal problems with hostname resolution. If your system uses libc rather than glibc2 , you probably will encounter some difficulties with hostname resolution and getpwnam() . This happens because glibc unfortunately depends on some external libraries to implement hostname resolution and getpwent() , even when compiled with -static . These problems manifest themselves in two ways:

• You probably will see the following error message when you run mysql_install_db :

  
  

   Sorry, the host '  xxxx  ' could not be looked up 

  
  

  You can deal with this by executing mysql_install_db --force , which will not execute the resolveip test in mysql_install_db . The downside is that you can't use hostnames in the grant tables: Except for localhost , you must use IP numbers instead. If you are using an old version of MySQL that doesn't support --force , you must manually remove the resolveip test in mysql_install using an editor.

• You also may see the following error when you try to run mysqld with the --user option:

  
  

   getpwnam: No such file or directory 

  
  

  To work around this, start mysqld by using the su command rather than by specifying the --user option. This causes the system itself to change the user ID of the mysqld process so that mysqld need not do so.

Another solution, which solves both problems, is to not use a binary distribution. Get a MySQL source distribution (in RPM or tar.gz format) and install that instead.

On some Linux 2.2 versions, you may get the error Resource temporarily unavailable when clients make a lot of new connections to a mysqld server over TCP/IP. The problem is that Linux has a delay between the time that you close a TCP/IP socket and the time that the system actually frees it. There is room for only a finite number of TCP/IP slots, so you will encounter the resource-unavailable error if clients attempt too many new TCP/IP connections during a short time. For example, you may see the error when you run the MySQL test-connect benchmark over TCP/IP.

We have inquired about this problem a few times on different Linux mailing lists but have never been able to find a suitable resolution. The only known "fix" is for the clients to use persistent connections, or, if you are running the database server and clients on the same machine, to use Unix socket file connections rather than TCP/IP connections.

2.6.1.3 Linux Source Distribution Notes

The following notes regarding glibc apply only to the situation when you build MySQL yourself. If you are running Linux on an x86 machine, in most cases it is much better for you to just use our binary. We link our binaries against the best patched version of glibc we can come up with and with the best compiler options, in an attempt to make it suitable for a high-load server. For a typical user, even for setups with a lot of concurrent connections or tables exceeding the 2GB limit, our binary is the best choice in most cases. After reading the following text, if you are in doubt about what to do, try our binary first to see whether it meets your needs. If you discover that it is not good enough, then you may want to try your own build. In that case, we would appreciate a note about it so that we can build a better binary next time.

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. You can get LinuxThreads at http://dev.mysql.com/downloads/os-linux.html.

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 issue INSERT DELAYED statements. We recommend that you not use INSERT DELAYED before upgrading glibc .

Note that Linux kernel and the LinuxThread library can by default only have 1,024 threads. If you plan to have more than 1,000 concurrent connections, you will need to make some changes to LinuxThreads:

• Increase PTHREAD_THREADS_MAX in sysdeps/unix/sysv/linux/bits/local_lim.h to 4096 and decrease STACK_SIZE in linuxthreads/internals.h to 256KB. 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 2MB.)

• Recompile LinuxThreads to produce a new libpthread.a library, and relink MySQL against it.

The page http://www.volano.com/linuxnotes.html contains additional information about circumventing thread limits in LinuxThreads.

There is another issue that greatly hurts MySQL performance, especially on SMP systems. The mutex implementation in LinuxThreads in glibc 2.1 is very bad for programs with many threads that hold the mutex only for a short time. This produces a paradoxical result: If you link MySQL against an unmodified LinuxThreads, removing processors from an SMP actually improves MySQL performance in many cases. We have made a patch available for glibc 2.1.3 to correct this behavior (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).

With glibc 2.2.2, MySQL 3.23.36 will use the adaptive mutex, which is much better than even the patched one in glibc 2.1.3. Be warned , however, that under some conditions, the current mutex code in glibc 2.2.2 overspins, which hurts MySQL performance. The likelihood that this condition will occur can be reduced by renicing the mysqld process to the highest priority. We have also been able to correct the overspin behavior with a patch, available at http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. It combines the correction of overspin, maximum number of threads, and stack spacing all in one. You will need to apply it in the linuxthreads directory with patch -p0 </tmp/linuxthreads-2.2.2.patch . We hope it will be included in some form in future releases of glibc 2.2. In any case, if you link against glibc 2.2.2, you still need to correct STACK_SIZE and PTHREAD_THREADS_MAX . We hope that the defaults will be corrected to some more acceptable values for high-load MySQL setup in the future, so that the commands needed to produce your own build can be reduced to ./configure; make; make install .

We recommend that you use these patches to build a special static version of libpthread.a and use it only for statically linking against MySQL. We know that the patches are safe for MySQL and significantly improve its performance, but we cannot say anything about other applications. If you link other applications that require LinuxThreads against the patched static version of the library, or build a patched shared version and install it on your system, you do so at your own risk.

If you experience any strange problems during the installation of MySQL, or with some common utilities hanging, it is very likely that they are either library or compiler related. If this is the case, using our binary will resolve them.

If you link your own MySQL client programs, you may see the following error at runtime:

 ld.so.1: fatal: libmysqlclient.so.#: open failed: No such file or directory 

This problem can be avoided by one of the following methods :

• Link clients with the -Wl,r/ full/ path /to /libmysqlclient.so flag rather than with -L path ).

• 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 

2.6.1.4 Linux Post-Installation Notes

mysql.server can be found in the support-files directory under the MySQL installation directory or in a MySQL source tree. You can install it as /etc/init.d/mysql for automatic MySQL startup and shutdown. See Section 2.4.3, "Starting and Stopping MySQL Automatically."

If MySQL can't open enough files or connections, it may be that you haven't configured Linux to handle enough files.

In Linux 2.2 and onward, you can check the number of allocated file handles as follows :

 shell>  cat /proc/sys/fs/file-max  shell>  cat /proc/sys/fs/dquot-max  shell>  cat /proc/sys/fs/super-max  

If you have more than 16MB of memory, you should add something like the following to your init scripts (for example, /etc/init.d/boot.local on SuSE Linux):

 echo 65536 > /proc/sys/fs/file-max echo 8192 > /proc/sys/fs/dquot-max echo 1024 > /proc/sys/fs/super-max 

You can also run the echo commands from the command line as root , but these settings will be lost the next time your computer restarts.

Alternatively, you can set these parameters on startup by using the sysctl tool, which is used by many Linux distributions (SuSE has added it as well, beginning with SuSE Linux 8.0). Just put the following values into a file named /etc/sysctl.conf :

 # Increase some values for MySQL fs.file-max = 65536 fs.dquot-max = 8192 fs.super-max = 1024 

You should also add the following to /etc/my.cnf :

 [mysqld_safe] open-files-limit=8192 

This should allow the server a limit of 8,192 for the combined number of connections and open files.

The 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 each individual thread stack, but small enough to keep the stack of some threads from running into the global mysqld data. Unfortunately, as we have experimentally discovered , the Linux implementation of mmap() 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 "gentlemanly" behavior of the code that creates threads. The user must take measures to make sure that 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 behavior by setting a reasonable value for the max_connections variable.

If you build MySQL yourself, you can patch LinuxThreads for better stack use. See Section 2.6.1.3, "Linux Source Distribution Notes." If you do not want to patch 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 2GB patch. If you are using our binary or RPM version 3.23.25 or later, you can safely set max_connections at 1500, 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 values between 128KB and 256KB.

If you use a lot of concurrent connections, you may suffer from a "feature" in the 2.2 kernel that attempts to prevent fork bomb attacks by penalizing a process for forking or cloning a child. This causes MySQL not to scale well as you increase the number of concurrent clients. On single-CPU systems, we have seen this manifested as very slow thread creation: It may take a long time to connect to MySQL (as long as one 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. The patch is available at http://www.mysql.com/Downloads/Patches/linux-fork.patch. We have now done rather extensive testing of this patch on both development and production systems. It has significantly improved MySQL performance without causing any problems and we now recommend it to our users who still run high-load servers on 2.2 kernels .

This issue has been fixed in the 2.4 kernel, so if you are not satisfied with the current performance of your system, rather than patching your 2.2 kernel, it might be easier to upgrade to 2.4. On SMP systems, upgrading also will give you a nice SMP boost in addition to fixing the fairness bug.

We have tested MySQL on the 2.4 kernel on a two-CPU machine and found MySQL scales much better. There was virtually no slowdown on query throughput all the way up to 1,000 clients, and the MySQL scaling factor (computed as the ratio of maximum throughput to the throughput for one client) was 180%. We have observed similar results on a four-CPU system: Virtually no slowdown as the number of clients was increased up to 1,000, and a 300% scaling factor. Based on these results, for a high-load SMP server using a 2.2 kernel, we definitely recommend upgrading to the 2.4 kernel at this point.

We have discovered that it is essential to run the mysqld process with the highest possible priority on the 2.4 kernel to achieve maximum performance. This can be done by adding a renice -20 $$ command to mysqld_safe . In our testing on a four-CPU machine, increasing the priority resulted in a 60% throughput increase with 400 clients.

We are currently also trying to collect more information on how well MySQL performs with a 2.4 kernel on four-way and eight-way systems. If you have access such a system and have done some benchmarks, please send an email message to [e-mail] with the results. We will review them for inclusion in the manual.

If you see a dead mysqld server process with ps , this usually means that you have found a bug in MySQL or you have a corrupted table. See Section A.4.2, "What to Do If MySQL Keeps 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 mysqld_safe or starting mysqld_safe with --core-file-size=1000000 . See Section 4.1.3, "The mysqld_safe Server Startup Script."

2.6.1.5 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 Red Hat, so if you have problems, check whether there are any updates. The glibc 2.0.7-19 and 2.0.7-29 RPMs are known to work.

If you are using Red Hat 8.0 or a new glibc 2.2.x library, you may see mysqld die in gethostbyaddr() . This happens because the new glibc library requires a stack size greater than 128KB for this call. To fix the problem, start mysqld with the --thread-stack=192K option. (Use -O thread_stack=192K before MySQL 4.) This stack size is now the default on MySQL 4.0.10 and above, so you should not see the problem.

If you are using gcc 3.0 and above to compile MySQL, you must install the libstdc ++v3 library before compiling MySQL; if you don't do this, you will get an error about a missing __cxa_pure_virtual symbol during linking.

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. Add an extra underscore to the _P macro name that has only one underscore, then try again.

You may get some warnings when compiling. Those shown here can be ignored:

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

If mysqld always dumps core when it starts, 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.

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  

If mysqld crashes immediately and you are running Red Hat Version 5.0 with a version of glibc older than 2.0.7-5, you should make sure that you have installed all glibc patches. There is a lot of information about this in the MySQL mail archives, available online at http://lists.mysql.com/.

2.6.1.6 Linux SPARC Notes

In some implementations , readdir_r() is broken. The symptom is that the SHOW DATABASES statement always returns an empty set. This can be fixed by removing HAVE_READDIR_R from config.h after configuring and before compiling.

2.6.1.7 Linux Alpha Notes

MySQL 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 and test suite, and it appears to work nicely .

We currently build the MySQL binary packages on SuSE Linux 7.0 for AXP, kernel 2.4.4-SMP, Compaq C compiler (V6.2-505) and Compaq C++ compiler (V6.3-006) on a Compaq DS20 machine with an Alpha EV6 processor.

You can find the preceding compilers at http://www.support.compaq.com/alpha-tools/. By using these compilers rather than gcc , we get about 9-14% better MySQL performance.

Note that until MySQL version 3.23.52 and 4.0.2, we optimized the binary for the current CPU only (by using the -fast compile option). This means that for older versions, you can use our Alpha binaries only if you have an Alpha EV6 processor.

For all following releases, we added the -arch generic flag to our compile options, which makes sure that the binary runs on all Alpha processors. We also compile statically to avoid library problems. The configure command looks like this:

 CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \ CXXFLAGS="-fast -arch generic -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="-O3 -fomit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -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 use gdb 5.1 instead.

• If you try linking mysqld statically when using gcc , the resulting image will dump core at startup time. In other words, do not use --with-mysqld-ldflags=-all-static with gcc .

2.6.1.8 Linux PowerPC Notes

MySQL should work on MkLinux with the newest glibc package (tested with glibc 2.0.7).

2.6.1.9 Linux MIPS 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).

2.6.1.10 Linux IA-64 Notes

To get MySQL to compile on Linux IA-64, we use the following configure command for building with gcc 2.96:

 CC=gcc \ CFLAGS="-O3 -fno-omit-frame-pointer" \ CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \     -fno-exceptions -fno-rtti" \     ./configure --prefix=/usr/local/mysql \     "--with-comment=Official MySQL binary" \     --with-extra-charsets=complex 

On IA-64, the MySQL client binaries use shared libraries. This means that if you install our binary distribution at a location other than /usr/local/mysql , you need to add the path of the directory where you have libmysqlclient.so installed either to the /etc/ld.so.conf file or to the value of your LD_LIBRARY_PATH environment variable.

See Section A.3.1, "Problems Linking to the MySQL Client Library."

2.6.2 Mac OS X Notes

On Mac OS X, tar cannot handle long filenames. If you need to unpack a .tar.gz distribution, use gnutar instead.

2.6.2.1 Mac OS X 10.x (Darwin)

MySQL should work without any problems on Mac OS X 10.x (Darwin).

Our binary for Mac OS X is compiled on Darwin 6.3 with the following configure line:

 CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \     -fno-exceptions -fno-rtti" \     ./configure --prefix=/usr/local/mysql \     --with-extra-charsets=complex --enable-thread-safe-client \     --enable-local-infile --disable-shared 

See Section 2.2.3, "Installing MySQL on Mac OS X."

2.6.2.2 Mac OS X Server 1.2 (Rhapsody)

For current versions of Mac OS X Server, no operating system changes are necessary before compiling MySQL. Compiling for the Server platform is the same as for the client version of Mac OS X. (However, note that MySQL comes preinstalled on Mac OS X Server, so you need not build it yourself.)

For older versions (Mac OS X Server 1.2, a.k.a. Rhapsody), you must first install a pthread package before trying to configure MySQL.

See Section 2.2.3, "Installing MySQL on Mac OS X."

2.6.3 Solaris Notes

On Solaris, you may run into trouble even before you get the MySQL distribution unpacked! Solaris tar can't handle long filenames, 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://dev.mysql.com/downloads/os-solaris.html.

Sun native threads work only on Solaris 2.5 and higher. For Version 2.4 and earlier, MySQL automatically uses MIT-pthreads. See Section 2.3.5, "MIT-pthreads Notes."

If you get the following error from configure , it means that you have something wrong with your compiler installation:

 checking for restartable system calls... configure: error can not run test programs while cross compiling 

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 or 3.2. You can find this at http://gcc.gnu.org/. Note that egcs 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="-O3" \ CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory \     --enable-assembler 

If you have an UltraSPARC system, you can get 4% better performance by adding -mcpu=v8 -Wa,-xarch=v8plusa to the CFLAGS and CXXFLAGS environment variables .

If you have Sun's Forte 5.0 (or newer) compiler, you can run configure like this:

 CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt" \ CXX=CC CXXFLAGS="-noex -mt" \ ./configure --prefix=/usr/local/mysql --enable-assembler 

To create a 64-bit binary with Sun's Forte compiler, use the following configuration options:

 CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt -xarch=v9" \ CXX=CC CXXFLAGS="-noex -mt -xarch=v9" ASFLAGS="-xarch=v9" \ ./configure --prefix=/usr/local/mysql --enable-assembler 

To create a 64-bit Solaris binary using gcc , add -m64 to CFLAGS and CXXFLAGS and remove --enable-assembler from the configure line. This works only with MySQL 4.0 and up; MySQL 3.23 does not include the required modifications to support this.

In the MySQL benchmarks, we got a 4% speedup on an UltraSPARC when using Forte 5.0 in 32-bit mode compared to using gcc 3.2 with the -mcpu flag.

If you create a 64-bit mysqld binary, it is 4% slower than the 32-bit binary, but can handle more threads and memory.

If you get a problem with fdatasync or sched_yield , you can fix this by adding LIBS=-lrt to the configure line.

For compilers older than WorkShop 5.3, you might have to edit the configure script. 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 following error message when you run it, you have tried to compile MySQL with the Sun compiler without enabling the -mt multi-thread option:

 libc internal error: _rmutex_unlock: rmutex not held 

Add -mt to CFLAGS and CXXFLAGS and recompile.

If you are using the SFW version of gcc (which comes with Solaris 8), you must add /opt/sfw/lib to the environment variable LD_LIBRARY_PATH before running configure .

If you are using the gcc available from sunfreeware.com, you may have many problems. To avoid this, you should recompile gcc and GNU binutils on the machine where you will be running them.

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 one of the following errors:

 ld: fatal: library -ldl: not found undefined reference to `dlopen' cannot find -lrt 

If you link your own MySQL client programs, you may see the following error at runtime:

 ld.so.1: fatal: libmysqlclient.so.#: open failed: No such file or directory 

This problem can be avoided by one of the following methods:

• Link clients with the -Wl,r/ full/path/to /libmysqlclient.so flag rather than with -L path ).

• Copy libmysqclient.so to /usr/lib .

• Add the pathname of the directory where libmysqlclient.so is located to the LD_RUN_PATH environmentvariable before running your client.

If you have problems with configure trying to link with -lz when 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 .

• Run configure with the --with-named-z-libs=no option when building MySQL.

If you are using gcc and have problems with loading user-defined functions (UDFs) into MySQL, try adding -lgcc to the link line for the UDF.

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 .

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 --back_log=50 option as a workaround for this. (Use -O back_log=50 before MySQL 4.)

Solaris doesn't support core files for setuid() applications, so you can't get a core file from mysqld if you are using the --user option.

2.6.3.1 Solaris 2.7/2.8 Notes

Normally, you can 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.

MySQL 3.23.4 and above should be able to detect new versions of Solaris automatically 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 fix the problem by copying /usr/include/widec.h to .../lib/gcc-lib/os/gcc-version/include and changing line 41 from this:

 #if     !defined(lint) && !defined(__lint) 

To this:

 #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 the following errors 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 problem is to do one of the following:

• Configure with CFLAGS=-DHAVE_CURSES_H CXXFLAGS=-DHAVE_CURSES_H ./configure .

• Edit /usr/include/widec.h as indicated in the preceding discussion and re-run configure .

• Remove the #define HAVE_TERM line from the config.h file and run make again.

If your linker can't find -lz when linking client programs, the problem is probably that your libz.so file is installed in /usr/local/lib . You can fix this problem 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.

• Run configure with the --with-named-z-libs=no option when building MySQL.

2.6.3.2 Solaris x86 Notes

On Solaris 8 on x86, mysqld will dump core if you remove the debug symbols using strip .

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="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \ CXX=gcc \ CXXFLAGS="-O3 -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 .

2.6.4 BSD Notes

This section provides information about using MySQL on variants of BSD Unix.

2.6.4.1 FreeBSD Notes

FreeBSD 4.x or newer is recommended for running MySQL, because the thread package is much more integrated. To get a secure and stable system, you should use only FreeBSD kernels that are marked -RELEASE .

The easiest (and preferred) way to install MySQL is to use the mysql-server and mysql-client ports available at http://www.freebsd.org/. Using these ports gives you the following benefits:

• A working MySQL with all optimizations enabled that are known to work on your version of FreeBSD.

• Automatic configuration and build.

• Startup scripts installed in /usr/local/etc/rc.d .

• The ability to use pkg_info -L to see which files are installed.

• The ability to use pkg_delete to remove MySQL if you no longer want it on your machine.

It is recommended 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 .

Unfortunately, certain function calls on FreeBSD are not yet fully thread-safe. Most notably, this includes the gethostbyname() function, which is used by MySQL to convert hostnames into IP addresses. Under certain circumstances, the mysqld process will suddenly cause 100% CPU load and will be unresponsive . If you encounter this problem, try to start MySQL using the --skip-name-resolve option.

Alternatively, you can link MySQL on FreeBSD 4.x against the LinuxThreads library, which avoids a few of the problems that the native FreeBSD thread implementation has. For a very good comparison of LinuxThreads versus native threads, see Jeremy Zawodny's article "FreeBSD or Linux for your MySQL Server?" at http://jeremy.zawodny.com/blog/archives/000697.html.

A known problem when using LinuxThreads on FreeBSD is that the wait_timeout value is not honored (probably a signal handling problem in FreeBSD/LinuxThreads). This is supposed to be fixed in FreeBSD 5.0. The symptom is that persistent connections can hang for a very long time without getting closed down.

The MySQL build process requires GNU make ( gmake ) to work. If GNU make is not available, you must install it first before compiling MySQL.

The recommended way to compile and install MySQL on FreeBSD with gcc (2.95.2 and up) is:

 CC=gcc CFLAGS="-O2 -fno-strength-reduce" \     CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions \     -felide-constructors -fno-strength-reduce" \     ./configure --prefix=/usr/local/mysql --enable-assembler gmake gmake install cd /usr/local/mysql bin/mysql_install_db --user=mysql bin/mysqld_safe & 

If you notice that configure will use MIT-pthreads, you should read the MIT-pthreads notes. See Section 2.3.5, "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. To fix this problem, remove config.cache , then re-run configure with the --with-mit-threads option.

Be sure that your name resolver setup is correct. Otherwise, you may experience resolver delays or failures when connecting to mysqld . Also make sure that the localhost entry in the /etc/ hosts file is correct. The file should start with a line similar to this:

 127.0.0.1       localhost localhost.your.domain 

FreeBSD is known to have a very low default file handle limit. See Section A.2.17, "File Not Found." Start the server by using the --open-files-limit option for mysqld_safe , or raise the limits for the mysqld user in /etc/login.conf and rebuild it with cap_mkdb /etc/login.conf . Also be sure that you set the appropriate class for this user in the password file if you are not using the default (use chpass mysqld-user-name ). See Section 4.1.3, "The mysqld_safe Server Startup Script."

If you have a lot of memory, you should consider rebuilding the kernel to allow MySQL to use more than 512MB of RAM. Take a look at option MAXDSIZ in the LINT config file for more information.

If you get problems with the current date in MySQL, setting the TZ variable will probably help. See Appendix B, "Environment Variables."

2.6.4.2 NetBSD Notes

To compile on NetBSD, you need GNU make . Otherwise, the build process will fail when make tries to run lint on C++ files.

2.6.4.3 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 

2.6.4.4 OpenBSD 2.8 Notes

Our users have reported that OpenBSD 2.8 has a threading bug that causes problems with MySQL. The OpenBSD Developers have fixed the problem, but as of January 25, 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.

If you get an error like Error in accept:: Bad file descriptor or error 9 when trying to open tables or directories, the problem is probably that you have not allocated enough file descriptors for MySQL.

In this case, try starting mysqld_safe as root with the following options:

 mysqld_safe --user=mysql --open-files-limit=2048 & 

2.6.4.5 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 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. See Appendix B, "Environment Variables."

2.6.4.6 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:

 env CXX=shlicc++ CC=shlicc2 \ ./configure \     --prefix=/usr/local/mysql \     --localstatedir=/var/mysql \     --without-perl \     --with-unix-socket-path=/var/mysql/mysql.sock 

The following is also known to work:

 env CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure \     --prefix=/usr/local/mysql \     --with-unix-socket-path=/var/mysql/mysql.sock 

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 its thread scheduler.

If you get the error virtual memory exhausted while compiling, you should try using ulimit -v 80000 and running 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 .

2.6.4.7 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 having asked for that to happen.

The fix is to either upgrade MySQL to at least version 3.23.34 or, after running configure , remove the line #define HAVE_REALPATH from config.h before running make .

Note that this means that you can't symbolically link a database directory to another database directory or symbolic link a table to another database on BSDI. (Making a symbolic link to another disk is okay.)

2.6.5 Other Unix Notes

2.6.5.1 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 (such as -O6 ) because they may not be safe on HP-UX.

The following configure line should work with gcc 2.95:

 CFLAGS="-I/opt/dce/include -fpic" \ CXXFLAGS="-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 

The following configure line should work with gcc 3.1:

 CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc \ CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors \     -fno-exceptions -fno-rtti -O3 -fPIC" \ ./configure --prefix=/usr/local/mysql \     --with-extra-charsets=complex --enable-thread-safe-client \     --enable-local-infile  --with-pthread \     --with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC     --disable-shared 

2.6.5.2 HP-UX Version 11.x Notes

For HP-UX Version 11.x, we recommend MySQL 3.23.15 or later.

Because of some critical bugs in the standard HP-UX libraries, you should install the following patches before trying to run MySQL on HP-UX 11.0:

 PHKL_22840 Streams cumulative PHNE_22397 ARPA cumulative 

This will solve the problem of getting EWOULDBLOCK from recv() and EBADF from accept() in threaded applications.

If you are using gcc 2.95.1 on an unpatched HP-UX 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.

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 . Look for this line:

 extern int pthread_atfork(void (*prepare)(), void (*parent)(),                                           void (*child)()); 

Change it to look like this:

 extern int pthread_atfork(void (*prepare)(void), void (*parent)(void),                                           void (*child)(void)); 

After making the change, the following configure line should work:

 CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" \ ./configure --prefix=/usr/local/mysql --disable-shared 

If you are using MySQL 4.0.5 with the HP-UX compiler, you can use the following command (which has been tested with cc B.11.11.04):

 CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure \     --with-extra-character-set=complex 

You can ignore any errors of the following type:

 aCC: warning 901: unknown option: `-3': use +help for online documentation 

If you get the following error from configure , verify that you don't have the path to the K&R compiler before the path to the HP-UX C and C++ compiler:

 checking for cc option to accept ANSI C... no configure: error: MySQL requires an ANSI C compiler (and a C++ compiler). Try gcc. See the Installation chapter in the Reference Manual. 

Another reason for not being able to compile is that you didn't define the +DD64 flags as just described.

Another possibility for HP-UX 11 is to use MySQL binaries for HP-UX 10.20. We have received reports from some users that these binaries work fine on HP-UX 11.00. If you encounter problems, be sure to check your HP-UX patch level.

2.6.5.3 IBM-AIX notes

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 \                 --sysconfdir=/etc/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 -O3 to -O2 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 or egcs to compile MySQL, you must use the -fno-exceptions flag, because 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 that 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=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 

The -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 don't know if the -fno-exceptions is required with gcc 2.95 , but because MySQL doesn't use exceptions and the option generates faster code, we recommend that you should always use it with egcs / gcc .

If you get a problem with assembler code, try changing the -mcpu= xxx option to match your CPU. Typically power2 , power , or powerpc may need to be used. Alternatively, you might need to use 604 or 604e . We are not positive but suspect that power would likely be safe most of the time, even on a power2 machine.

If you don't know what your CPU is, execute a uname -m command. It will produce a string that looks like 000514676700 , with a format of xxyyyyyymmss where xx and ss are always 00 , yyyyyy is a unique system ID and mm is the ID of the CPU Planar. A chart of these values can be found at http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/uname.htm. This will give you a machine type and a machine model 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 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() 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 config.h and include/my_config.h and change the line that says this:

 #define HAVE_SNPRINTF 1 

to this:

 #undef HAVE_SNPRINTF 

And finally, in mysqld.cc , you need to add a prototype for initgroups() :

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

If you need to allocate a lot of memory to the mysqld process, it's not enough to just use ulimit -d unlimited . You may also have to modify mysqld_safe to add a line something like this:

 export LDR_CNTRL='MAXDATA=0x80000000' 

You can find more information about using a lot of memory at http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm.

2.6.5.4 SunOS 4 Notes

On SunOS 4, MIT-pthreads is needed to compile MySQL. This 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:

 ./configure --disable-shared --with-mysqld-ldflags=-all-static 

When compiling readline , you may get warnings about duplicate defines. These can be ignored.

When compiling mysqld , there will be some implicit declaration of function warnings. These can be ignored.

2.6.5.5 Alpha-DEC-Unix Notes (Tru64)

If you are using egcs 1.1.2 on Digital Unix, you should upgrade to gcc 2.95.2, because 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 -lmach -lexc libraries (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:

 nohup mysqld [  options  ] & 

nohup causes the command following it to ignore any SIGHUP signal sent from the terminal. Alternatively, start the server by running mysqld_safe , which invokes mysqld using nohup for you. See Section 4.1.3, "The mysqld_safe Server Startup Script."

If you get a problem when compiling mysys/get_opt.c , just remove the #define _NO_PROTO line from the start of that file.

If you are using Compaq's CC compiler, the following configure line should work:

 CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host" CXX="cxx -pthread" CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all \     -arch host -noexceptions -nortti" 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 just shown, when linking mysql , you should be able to get around this by issuing these commands:

 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 

2.6.5.6 Alpha-DEC-OSF/1 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 OSF/1 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 occurring 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 OSF/1, 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 . The 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:

 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:

 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 directory and run make again.

2.6.5.7 SGI Irix Notes

If you are using Irix Version 6.5.3 or newer, mysqld will be able to create threads only if you run it as a user that has CAP_SCHED_MGT privileges (such as root ) or give the mysqld server this privilege with the following shell command:

 chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld 

You may have to undefine some symbols 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 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 definitely 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 

Type the following in the top-level directory of your MySQL source tree:

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

There have also been reports of scheduling problems. If only one thread is running, performance is slow. Avoid this by starting another client. This may lead to a two-to-tenfold 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 --enable-thread-safe-client \     --with-named-thread-libs=-lpthread 

On Irix 6.5.11 with native Irix C and C++ compilers ver. 7.3.1.2, the following is reported to work

 CC=cc CXX=CC CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include \ -L/usr/local/lib' CXXFLAGS='-O3 -n32 -TARG:platform=IP22 \ -I/usr/local/include -L/usr/local/lib' \ ./configure --prefix=/usr/local/mysql --with-innodb --with-berkeley-db \     --with-libwrap=/usr/local \     --with-named-curses-libs=/usr/local/lib/libncurses.a 

2.6.5.8 SCO Notes

The current port is tested only on "sco3.2v5.0.5," "sco3.2v5.0.6," and "sco3.2v5.0.7" systems. 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 gcc-2.95.2p1 or newer from the Skunkware. Go to http://www.sco.com/skunkware/ and choose browser OpenServer packages or by FTP to ftp2.caldera.com in the pub/skunkware/osr5/devtools/gcc directory.
   
   
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://moss.csc.ncsu.edu/~mueller/ftp/pub/PART/pthreads.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 using 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. For 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:
   
   

   1. Run ./configure in the threads/src directory and select the SCO OpenServer option. This command copies Makefile.SCO5 to Makefile .
   
   

   2. Run make .
   
   

   3. To install in the default /usr/include directory, log in 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 mysqld_safe 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:
   
   

   
   

    ./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:
   
   

   
   

    CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \ ./configure \     --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 library functions are re-entrant, so they must be re-entrant 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() .

• The CSSA-2001-SCO.35.2 (the patch is listed in custom as erg711905-dscr_remap security patch (version 2.0.0)) breaks FSU threads and makes mysqld unstable. You have to remove this one if you want to run mysqld on an OpenServer 5.0.6 machine.

• SCO provides operating system patches at ftp://ftp.sco.com/pub/openserver5 for OpenServer 5.0.x.

• SCO provides security fixes and libsocket.so.2 at ftp://ftp.sco.com/pub/security/OpenServer and ftp://ftp.sco.com/pub/security/sse for OpenServer 5.0.x.

• pre-OSR506 security fixes. Also, the telnetd fix at ftp://stage.caldera.com/pub/security/openserver/ or ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.10/ as both libsocket.so.2 and libresolv.so.1 with instructions for installing on pre-OSR506 systems.

  It's probably a good idea to install these patches before trying to compile/use MySQL.

2.6.5.9 SCO UnixWare Version 7.1.x Notes

On UnixWare 7.1.0, you must use a version of MySQL at least as recent as 3.22.13 to get fixes for some portability and OS problems.

We have been able to compile MySQL with the following configure command on UnixWare Version 7.1.x:

 CC=cc CXX=CC ./configure --prefix=/usr/local/mysql 

If you want to use gcc , you must use gcc 2.95.2 or newer.

 CC=gcc CXX=g++ ./configure --prefix=/usr/local/mysql 

SCO provides operating system patches at ftp://ftp.sco.com/pub/unixware7 for UnixWare 7.1.1 and 7.1.3 and at ftp://ftp.sco.com/pub/openunix8 for OpenUNIX 8.0.0.

SCO provides information about security fixes at ftp://ftp.sco.com/pub/security/OpenUNIX for OpenUNIX and at ftp://ftp.sco.com/pub/security/UnixWare for UnixWare.

2.6.6 OS/2 Notes

MySQL uses quite a few open files. Because of this, you should add something like the following to your CONFIG.SYS file:

 SET EMXOPT=-c -n -h1024 

If you don't do this, you will probably run into the following error:

 File '  xxxx  ' not found (Errcode: 24) 

When using MySQL with OS/2 Warp 3, FixPack 29 or above is required. With OS/2 Warp 4, FixPack 4 or above is required. This is a requirement of the Pthreads library. MySQL must be installed on a partition with a type that supports long filenames, such as HPFS, FAT32, and so on.

The INSTALL.CMD script must be run from OS/2's own CMD.EXE and may not work with replacement shells such as 4OS2.EXE .

The scripts/mysql-install-db script has been renamed . It is now called install.cmd and is a REXX script, which will set up the default MySQL security settings and create the WorkPlace Shell icons for MySQL.

Dynamic module support is compiled in but not fully tested. Dynamic modules should be compiled using the Pthreads runtime library.

 gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \     -o example udf_example.cc -L../lib -lmysqlclient udf_example.def mv example.dll example.udf 

Note: Due to limitations in OS/2, UDF module name stems must not exceed eight characters . Modules are stored in the /mysql2/udf directory; the safe-mysqld.cmd script will put this directory in the BEGINLIBPATH environment variable. When using UDF modules, specified extensions are ignored ”it is assumed to be .udf . For example, in Unix, the shared module might be named example.so and you would load a function from it like this:

 mysql>  CREATE FUNCTION metaphon RETURNS STRING SONAME 'example.so';  

In OS/2, the module would be named example.udf , but you would not specify the module extension:

 mysql>  CREATE FUNCTION metaphon RETURNS STRING SONAME 'example';  

2.6.7 BeOS Notes

We have in the past talked with some BeOS developers who have said that MySQL is 80% ported to BeOS, but we haven't heard from them in a while.