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.