For information about installing MySQL on Solaris using PKG distributions, see Installing MySQL on Solaris.
On Solaris, you may run into trouble even before you get the MySQL distribution unpacked, as the Solaris tar cannot handle long file names. This means that you may see errors when you try to unpack MySQL.
If this occurs, you must use GNU tar (gtar) to unpack the distribution.
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.
In the MySQL benchmarks, we obtained a 4% speed increase on
UltraSPARC when using Forte 5.0 in 32-bit mode, as 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.
When using Solaris 10 for x86_64, you should mount any file
systems on which you intend to store InnoDB
files with the forcedirectio option. (By
default mounting is done without this option.) Failing to do so
will cause a significant drop in performance when using the
InnoDB storage engine on this platform.
If you get a problem with fdatasync or
sched_yield, you can fix this by adding
LIBS=-lrt to the configure
line
Solaris does not provide static versions of all system libraries
(libpthreads and libdl), so
you cannot compile MySQL with --static. If you
try to do so, you 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:
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 should 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.)
To configure the generation of core files on Solaris you should
use the coreadm command. Because of the
security implications of generating a core on a
setuid() application, by default, Solaris does
not support core files on setuid() programs.
However, you can modify this behavior using
coreadm. If you enable
setuid() core files for the current user, they
will be generated using the mode 600 and owned by the superuser.
