MySqlTalk.com  

Go Back   MySqlTalk.com > MySQL > Documentation
User Name
Password
FAQ Members List Calendar Search Today's Posts Mark Forums Read


Reply
 
Thread Tools Search this Thread
Old 06-08-2004, 02:29 PM   #1
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2 Installing MySQL

From http://dev.mysql.com/doc/mysql/en/Installing.html
2 Installing MySQL



This chapter describes how to obtain and install MySQL:
  1. Determine whether your platform is supported. Please note that not all supported systems are equally good for running MySQL on them. On some it is much more robust and efficient than others. See section 2.1.1 Operating Systems Supported by MySQL for details.
  2. Choose which distribution to install. Several versions of MySQL are available, and most are available in several distribution formats. You can choose from pre-packaged distributions containing binary (precompiled) programs or source code. When in doubt, use a binary distribution. We also provide public access to our current source tree for those who want to see our most recent developments and help us test new code. To determine which version and type of distribution you should use, see section 2.1.2 Choosing Which MySQL Distribution to Install.
  3. Download the distribution that you want to install. For a list of sites from which you can obtain MySQL, see section 2.1.3 How to Get MySQL. You can verify the integrity of the distribution using the instructions in section 2.1.4 Verifying Package Integrity Using MD5 Checksums or GnuPG.
  4. Install the distribution. To install MySQL from a binary distribution, use the instructions in section 2.2 Standard MySQL Installation Using a Binary Distribution. To install MySQL from a source distribution or from the current development source tree, use the instructions in section 2.3 MySQL Installation Using a Source Distribution. Note: If you plan to upgrade an existing version of MySQL to a newer version rather than installing MySQL for the first time, see section 2.5 Upgrading/Downgrading MySQL for information about upgrade procedures and about issues that you should consider before upgrading. If you encounter installation difficulties, see section 2.6 Operating System-Specific Notes for information on solving problems for particular platforms.
  5. Perform any necessary post-installation setup. After installing MySQL, read section 2.4 Post-Installation Setup and Testing. This section contains important information about making sure the MySQL server is working properly. It also describes how to secure the initial MySQL user accounts, which have no passwords until you assign passwords. The section applies whether you install MySQL using a binary or source distribution.
  6. If you want to run the MySQL benchmark scripts, Perl support for MySQL must be available. See section 2.7 Perl Installation Notes.
DISCUSS:
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:29 PM   #2
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1 General Installation Issues

From http://dev.mysql.com/doc/mysql/en/Ge...on_Issues.html

2.1 General Installation Issues

Before installing MySQL, you should do the following:
  1. Determine whether or not MySQL runs on your platform.
  2. Choose a distribution to install.
  3. Download the distribution and verify its integrity.
This section contains the information necessary to carry out these steps. After doing so, you can use the instructions in later sections of the chapter to install the distribution that you choose.
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:30 PM   #3
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1.1 Operating Systems Supported by MySQL

From http://dev.mysql.com/doc/mysql/en/Which_OS.html

2.1.1 Operating Systems Supported by MySQL



This section lists the operating systems on which you can expect to be able to run MySQL.

We use GNU Autoconf, so it is possible to port MySQL to all modern systems that have a C++ compiler and a working implementation of POSIX threads. (Thread support is needed for the server. To compile only the client code, the only requirement is a C++ compiler.) We use and develop the software ourselves primarily on Linux (SuSE and Red Hat), FreeBSD, and Sun Solaris (Versions 8 and 9).

MySQL has been reported to compile successfully on the following combinations of operating system and thread package. Note that for many operating systems, native thread support works only in the latest versions.
Not all platforms are equally well-suited for running MySQL. How well a certain platform is suited for a high-load mission-critical MySQL server is determined by the following factors:
  • General stability of the thread library. A platform may have an excellent reputation otherwise, but MySQL will be only as stable as the thread library if that library is unstable in the code that is called by MySQL, even if everything else is perfect.
  • The capability of the kernel and the thread library to take advantage of symmetric multi-processor (SMP) systems. In other words, when a process creates a thread, it should be possible for that thread to run on a different CPU than the original process.
  • The capability of the kernel and the thread library to run many threads that acquire and release a mutex over a short critical region frequently without excessive context switches. In other words, if the implementation of pthread_mutex_lock() is too anxious to yield CPU time, this will hurt MySQL tremendously. If this issue is not taken care of, adding extra CPUs will actually make MySQL slower.
  • General filesystem stability and performance.
  • If your tables are big, the ability of the filesystem to deal with large files at all and to deal with them efficiently.
  • Our level of expertise here at MySQL AB with the platform. If we know a platform well, we enable platform-specific optimizations and fixes at compile time. We can also provide advice on configuring your system optimally for MySQL.
  • The amount of testing we have done internally for similar configurations.
  • The number of users that have successfully run MySQL on the platform in similar configurations. If this number is high, the chances of encountering platform-specific surprises are much smaller.
Based on the preceding criteria, the best platforms for running MySQL at this point are x86 with SuSE Linux using a 2.4 kernel, and ReiserFS (or any similar Linux distribution) and SPARC with Solaris (2.7-9). FreeBSD comes third, but we really hope it will join the top club once the thread library is improved. We also hope that at some point we will be able to include into the top category all other platforms on which MySQL currently compiles and runs okay, but not quite with the same level of stability and performance. This will require some effort on our part in cooperation with the developers of the operating system and library components that MySQL depends on. If you are interested in improving one of those components, are in a position to influence its development, and need more detailed instructions on what MySQL needs to run better, send an email message to the MySQL internals mailing list. See section 1.7.1.1 The MySQL Mailing Lists.

Please note that the purpose of the preceding comparison is not to say that one operating system is better or worse than another in general. We are talking only about choosing an OS for the specific purpose of running MySQL. With this in mind, the result of this comparison would be different if we considered more factors. In some cases, the reason one OS is better than the other could simply be that we have been able to put more effort into testing and optimizing for a particular platform. We are just stating our observations to help you decide which platform to use for running MySQL.
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:31 PM   #4
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1.2 Choosing Which MySQL Distribution to Install

From http://dev.mysql.com/doc/mysql/en/Which_version.html


2.1.2 Choosing Which MySQL Distribution to Install

When preparing to install MySQL, you should decide which version to use. MySQL development occurs in several release series, and you can pick the one that best fits your needs. After deciding which version to install, you can choose a distribution format. Releases are available in binary or source format.
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:32 PM   #5
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1.2.1 Choosing Which Version of MySQL to Install

From http://dev.mysql.com/doc/mysql/en/Choosing_version.html


2.1.2.1 Choosing Which Version of MySQL to Install

The first decision to make is whether you want to use a production (stable) release or a development release. In the MySQL development process, multiple release series co-exist, each at a different stage of maturity:
  • MySQL 5.0 is the newest development release series and is under very active development for new features. Until recently it was available only in preview form from the BitKeeper source repository. An early alpha release has now been issued to allow more widespread testing.
  • MySQL 4.1 is a development release series to which major new features have been added. It is still at alpha status. Sources and binaries are available for use and testing on development systems.
  • MySQL 4.0 is the current stable (production-quality) release series. New releases are issued for bugfixes. No new features are added that could diminish the code stability.
  • MySQL 3.23 is the old stable (production-quality) release series. This series is retired, so new releases are issued only to fix critical bugs.
We don't believe in a complete freeze, as this also leaves out bugfixes and things that ``must be done.'' ``Somewhat frozen'' means that we may add small things that ``almost surely will not affect anything that's already working.'' Naturally, relevant bugfixes from an earlier series propagate to later series.

Normally, if you are beginning to use MySQL for the first time or trying to port it to some system for which there is no binary distribution, we recommend going with the production release series. Currently this is MySQL 4.0. All MySQL releases, even those from development series, are checked with the MySQL benchmarks and an extensive test suite before being issued.

If you are running an old system and want to upgrade, but don't want to take chances with a non-seamless upgrade, you should upgrade to the latest version in the same release series you are using (where only the last part of the version number is newer than yours). We have tried to fix only fatal bugs and make small, relatively safe changes to that version.

If you want to use new features not present in the production release series, you can use a version from a development series. Note that development releases are not as stable as production releases.

If you want to use the very latest sources containing all current patches and bugfixes, you can use one of our BitKeeper repositories. These are not ``releases'' as such, but are available as previews of the code on which future releases will be based.



The MySQL naming scheme uses release names that consist of three numbers and a suffix; for example, mysql-4.1.0-alpha. The numbers within the release name are interpreted like this:
  • The first number (4) is the major version and also describes the file format. All Version 4 releases have the same file format.
  • The second number (1) is the release level. Taken together, the major version and release level constitute the release series number.
  • The third number (0) is the version number within the release series. This is incremented for each new release. Usually you want the latest version for the series you have chosen.
For each minor update, the last number in the version string is incremented. When there are major new features or minor incompatibilities with previous versions, the second number in the version string is incremented. When the file format changes, the first number is increased.

Release names also include a suffix to indicates the stability level of the release. Releases within a series progress through a set of suffixes to indicate how the stability level improves. The possible suffixes are:
  • alpha indicates that the release contains some large section of new code that hasn't been 100% tested. Known bugs (usually there are none) should be documented in the News section. See section C MySQL Change History. There are also new commands and extensions in most alpha releases. Active development that may involve major code changes can occur in an alpha release, but everything will be tested before issuing a release. For this reason, there should be no known bugs in any MySQL release.
  • beta means that all new code has been tested. No major new features that could cause corruption in old code are added. There should be no known bugs. A version changes from alpha to beta when there haven't been any reported fatal bugs within an alpha version for at least a month and we have no plans to add any features that could make any old command unreliable.
  • gamma is a beta that has been around a while and seems to work fine. Only minor fixes are added. This is what many other companies call a release.
  • If there is no suffix, it means that the version has been run for a while at many different sites with no reports of bugs other than platform-specific bugs. Only critical bugfixes are applied to the release. This is what we call a production (stable) release.
MySQL uses a naming scheme that is slightly different from most other products. In general, it's relatively safe to use any version that has been out for a couple of weeks without being replaced with a new version within the release series.

All releases of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Because the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better.



All releases have been tested at least with:

An internal test suite The `mysql-test' directory contains an extensive set of test cases. We run these tests for virtually every server binary. See section 23.1.2 MySQL Test Suite for more information about this test suite. The MySQL benchmark suite This suite runs a range of common queries. It is also a test to see whether the latest batch of optimizations actually made the code faster. See section 7.1.4 The MySQL Benchmark Suite. The crash-me test This test tries to determine what features the database supports and what its capabilities and limitations are. See section 7.1.4 The MySQL Benchmark Suite. Another test is that we use the newest MySQL version in our internal production environment, on at least one machine. We have more than 100GB of data to work with.
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:32 PM   #6
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1.2.2 Choosing a Distribution Format

From http://dev.mysql.com/doc/mysql/en/Ch...on_format.html


2.1.2.2 Choosing a Distribution Format

After choosing which version of MySQL to install, you should decide whether to use a binary distribution or a source distribution. In most cases, you should probably use a binary distribution, if one exists for your platform. Binary distributions are available in native format for many platforms, such as RPM files for Linux or DMG package installers for Mac OS X. Distributions also are available as Zip archives or compressed tar files.

Reasons to choose a binary distribution include the following:
  • Binary distributions generally are easier to install than source distributions.
  • To satisfy different user requirements, we provide two different binary versions: one compiled with the non-transactional storage engines (a small, fast binary), and one configured with the most important extended options like transaction-safe tables. Both versions are compiled from the same source distribution. All native MySQL clients can connect to servers from either MySQL version. The extended MySQL binary distribution is marked with the -max suffix and is configured with the same options as mysqld-max. See section 5.1.2 The mysqld-max Extended MySQL Server. If you want to use the MySQL-Max RPM, you must first install the standard MySQL-server RPM.
Under some circumstances, you probably will be better off installing MySQL from a source distribution:
  • You want to install MySQL at some explicit location. The standard binary distributions are ``ready to run'' at any place, but you may want to have even more flexibility to place MySQL components where you want.
  • You want to configure mysqld with some extra features that are not included in the standard binary distributions. Here is a list of the most common extra options that you may want to use:
    • --with-innodb (default for MySQL 4.0 and onwards)
    • --with-berkeley-db (not available on all platforms)
    • --with-raid
    • --with-libwrap
    • --with-named-z-libs (this is done for some of the binaries)
    • --with-debug[=full]
  • You want to configure mysqld without some features that are included in the standard binary distributions. For example, distributions normally are compiled with support for all character sets. If you want a smaller MySQL server, you can recompile it with support for only the character sets you need.
  • You have a special compiler (such as pgcc) or want to use compiler options that are better optimized for your processor. Binary distributions are compiled with options that should work on a variety of processors from the same processor family.
  • You want to use the latest sources from one of the BitKeeper repositories to have access to all current bugfixes. For example, if you have found a bug and reported it to the MySQL development team, the bugfix will be committed to the source repository and you can access it there. The bugfix will not appear in a release until a release actually is issued.
  • You want to read (or modify) the C and C++ code that makes up MySQL. For this purpose, you should get a source distribution, because the source code is always the ultimate manual.
  • Source distributions contain more tests and examples than binary distributions.
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:33 PM   #7
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1.2.3 How and When Updates Are Released

From http://dev.mysql.com/doc/mysql/en/Many_versions.html

2.1.2.3 How and When Updates Are Released



MySQL is evolving quite rapidly here at MySQL AB and we want to share new developments with other MySQL users. We try to make a release when we have very useful features that others seem to have a need for.

We also try to help out users who request features that are easy to implement. We take note of what our licensed users want to have, and we especially take note of what our extended email-supported customers want and try to help them out.

No one has to download a new release. The News section will tell you if the new release has something you really want. See section C MySQL Change History.

We use the following policy when updating MySQL:
  • Releases are issued within each series. For each release, the last number in the version is one more than the previous release within the same series.
  • Production (stable) releases are meant to appear about 1-2 times a year. However, if small bugs are found, a release with only bugfixes will be issued.
  • Working releases/bugfixes to old releases are meant to appear about every 4-8 weeks.
  • Binary distributions for some platforms are made by us for major releases. Other people may make binary distributions for other systems, but probably less frequently.
  • We make fixes available as soon as we have identified and corrected small or non-critical but annoying bugs. The fixes are available immediately from our public BitKeeper repositories, and will be included in the next release.
  • If by any chance a fatal bug is found in a release, we will make a new release as soon as possible. (We would like other companies to do this, too!)
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:34 PM   #8
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1.2.4 Release Philosophy--No Known Bugs in Releases

From http://dev.mysql.com/doc/mysql/en/Re...hilosophy.html


2.1.2.4 Release Philosophy--No Known Bugs in Releases

We put a lot of time and effort into making our releases bug-free. To our knowledge, we have not released a single MySQL version with any known ``fatal'' repeatable bugs. (A ``fatal'' bug is something that crashes MySQL under normal usage, produces incorrect answers for normal queries, or has a security problem.)

We have documented all open problems, bugs, and issues that are dependent on design decisions. See section 1.8.7 Known Errors and Design Deficiencies in MySQL.

Our aim is to fix everything that is fixable without risk of making a stable MySQL version less stable. In certain cases, this means we can fix an issue in the development versions, but not in the stable (production) version. Naturally, we document such issues so that users are aware.



Here is a description of how our build process works:
  • We monitor bugs from our customer support list, the bugs database at http://bugs.mysql.com/, and the MySQL external mailing lists.
  • All reported bugs for live versions are entered into the bugs database.
  • When we fix a bug, we always try to make a test case for it and include it into our test system to ensure that the bug will never recur without being detected. (About 90% of all fixed bugs have a test case.)
  • We create test cases for all new features we add to MySQL.
  • Before we start to build a new MySQL release, we ensure that all reported repeatable bugs for the MySQL version (3.23.x, 4.0.x, etc) are fixed. If something is impossible to fix (due to some internal design decision in MySQL), we document this in the manual. See section 1.8.7 Known Errors and Design Deficiencies in MySQL.
  • We do a build on all platforms for which we support binaries (15+ platforms) and run our test suite and benchmark suite on all of them.
  • We will not publish a binary for a platform for which the test or benchmark suite fails. If the problem is due to a general error in the source, we fix it and do the build plus tests on all systems again from scratch.
  • The build and test process takes 2-3 days. If we receive a report regarding a fatal bug during this process (for example, one that causes a core dump), we fix the problem and restart the build process.
  • After publishing the binaries on http://dev.mysql.com/, we send out an announcement message to the mysql and announce mailing lists. See section 1.7.1.1 The MySQL Mailing Lists. The announcement message contains a list of all changes to the release and any known problems with the release. The Known Problems section in the release notes has been needed for only a handful of releases.
  • To quickly give our users access to the latest MySQL features, we do a new MySQL release every 4-8 weeks. Source code snapshots are built daily and are available at http://downloads.mysql.com/snapshots.php.
  • If, after the release is done, we get any bug reports that, despite our best efforts, there was something critically wrong with the build on a specific platform, we will fix it at once and build a new 'a' release for that platform. Thanks to our large user base, problems are found quickly.
  • Our track record for making good releases is quite good. In the last 150 releases, we had to do a new build for fewer than 10 releases. In three of these cases, the bug was a faulty glibc library on one of our build machines that took us a long time to track down.
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:35 PM   #9
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
2.1.2.5 MySQL Binaries Compiled by MySQL AB

From http://dev.mysql.com/doc/mysql/en/MySQL_binaries.html

2.1.2.5 MySQL Binaries Compiled by MySQL AB



As a service of MySQL AB, we provide a set of binary distributions of MySQL that are compiled on systems at our site or on systems where supporters of MySQL kindly have given us access to their machines.

In addition to the binaries provided in platform-specific package formats, we offer binary distributions for a number of platforms in the form of of compressed tar files (.tar.gz files). See section 2.2 Standard MySQL Installation Using a Binary Distribution.

For Windows distributions, see section 2.2.1 Installing MySQL on Windows.

These distributions are generated using the script Build-tools/Do-compile, which compiles the source code and creates the binary tar.gz archive using scripts/make_binary_distribution.

These binaries are configured and built with the following compilers and options. This information can also be obtained by looking at the variables COMP_ENV_INFO and CONFIGURE_LINE inside the script bin/mysqlbug of every binary tar file distribution.

The following binaries are built on MySQL AB development systems:
Administrator is offline   Fork this post Reply With Quote
Old 06-08-2004, 02:36 PM   #10
Administrator
Administrator
 
Join Date: Jun 2004
Posts: 383 Administrator is on a distinguished road
Re: 2 Installing MySQL

continued...


Linux 2.4.xx x86 with gcc 2.95.3: CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc CXXFLAGS="-O2 -mcpu=pentiumpro -felide-constructors" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --disable-shared --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static Linux 2.4.xx Intel Itanium 2 with ecc (Intel C++ Itanium Compiler 7.0): CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline" CXX=ecc CXXFLAGS="-O2 -tpp2 -ip -nolib_inline" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile Linux 2.4.xx Intel Itanium with ecc (Intel C++ Itanium Compiler 7.0): CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile Linux 2.4.xx alpha with ccc (Compaq C V6.2-505 / Compaq C++ V6.3-006): CC=ccc CFLAGS="-fast -arch generic" CXX=cxx CXXFLAGS="-fast -arch generic -noexceptions -nortti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared --disable-shared Linux 2.x.xx ppc with gcc 2.95.4: 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 --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-embedded-server --with-innodb Linux 2.4.xx s390 with gcc 2.95.3: CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static Linux 2.4.xx x86_64 (AMD64) with gcc 3.2.1: CXX=gcc ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared Sun Solaris 8 x86 with gcc 3.2.3: 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 --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-innodb Sun Solaris 8 SPARC with gcc 3.2: 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 --enable-assembler --with-named-z-libs=no --with-named-curses-libs=-lcurses --disable-shared Sun Solaris 8 SPARC 64-bit with gcc 3.2: CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -m64 -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 --enable-assembler --with-named-z-libs=no --with-named-curses-libs=-lcurses --disable-shared Sun Solaris 9 SPARC with gcc 2.95.3: 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 --enable-assembler --with-named-curses-libs=-lcurses --disable-shared Sun Solaris 9 SPARC with cc-5.0 (Sun Forte 5.0): CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa -xstrconst -mt -D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt -D_FORTEC_ -xarch=v9" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=no --enable-thread-safe-client --disable-shared IBM AIX 4.3.2 ppc with gcc 3.2.3: CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared IBM AIX 4.3.3 ppc with xlC_r (IBM Visual Age C/C++ 6.0): CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared --with-innodb IBM AIX 5.1.0 ppc with gcc 3.3: CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared IBM AIX 5.2.0 ppc with xlC_r (IBM Visual Age C/C++ 6.0): CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" CXX=xlC_r CXXFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared --with-embedded-server --with-innodb HP-UX 10.20 pa-risc1.1 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 HP-UX 11.00 pa-risc with aCC (HP ANSI C++ B3910B A.03.50): CC=cc CXX=aCC CFLAGS=+DAportable CXXFLAGS=+DAportable ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-embedded-server --with-innodb HP-UX 11.11 pa-risc2.0 64bit with aCC (HP ANSI C++ B3910B A.03.33): CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared HP-UX 11.11 pa-risc2.0 32bit with aCC (HP ANSI C++ B3910B A.03.33): CC=cc CXX=aCC CFLAGS="+DAportable" CXXFLAGS="+DAportable" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-innodb HP-UX 11.22 ia64 64bit with aCC (HP aC++/ANSI C B3910B A.05.50): CC=cc CXX=aCC CFLAGS="+DD64 +DSitanium2" CXXFLAGS="+DD64 +DSitanium2" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-embedded-server --with-innodb Apple Mac OS X 10.2 powerpc with gcc 3.1: 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 FreeBSD 4.7 i386 with gcc 2.95.4: CFLAGS=-DHAVE_BROKEN_REALPATH ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=not-used --disable-shared FreeBSD 4.7 i386 using LinuxThreads with gcc 2.95.4: CFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads" CXXFLAGS="-DHAVE_BROKEN_REALPATH -D__USE_UNIX98 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads" ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-thread-libs="-DHAVE_GLIBC2_STYLE_GETHOSTBYNAME_R -D_THREAD_SAFE -I /usr/local/include/pthread/linuxthreads -L/usr/local/lib -llthread -llgcc_r" --disable-shared --with-embedded-server --with-innodb QNX Neutrino 6.2.1 i386 with gcc 2.95.3qnx-nto 20010315: 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
Administrator is offline   Fork this post Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Import Access, Excel and data of other formats to MySQL by Navicat NavicatGuy Articles 0 08-17-2004 01:08 AM
3.2 Entering Queries Administrator Documentation 0 06-09-2004 02:58 AM
1.4.3.2 Using the MySQL Software for Free Under GPL Administrator Documentation 0 06-08-2004 02:20 AM
1.2.2 The Main Features of MySQL Administrator Documentation 0 06-08-2004 01:55 AM
1.2 Overview of the MySQL Database Management System Administrator Documentation 0 06-07-2004 10:11 PM



All times are GMT -4. The time now is 05:54 AM.



Powered by: vBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Limited.
Google
  Web http://www.mysqltalk.com
DISCLAIMERS:
1. We have no commercial interest in this site.
Banner Ads and Subscriptions will only be used to help pay for hosting and maintenance costs.
2. MySQLTalk.com is NOT affiliated with MySQL AB in any way.
3. MySQLTalk.com is NOT endorsed by MySQL AB in any way.
4. Please do not post any content that is harmful to MySQL or MySQL AB, meaning no misleading or obsolete information will be tolerated.
Well-founded constructive criticism meant to help the community is permitted.
5. This website is founded with the goal of improving the MySQL community.
We not only tolerate newbies, we encourage them.
Please do not ask newbies to "read the manual".