mirror of https://github.com/postgres/postgres
683 lines
28 KiB
Plaintext
683 lines
28 KiB
Plaintext
PostgreSQL Installation Instructions
|
|
|
|
Table of Contents
|
|
Short Version
|
|
Requirements
|
|
If You Are Upgrading
|
|
Installation Procedure
|
|
Post-Installation Setup
|
|
Getting Started
|
|
What Now?
|
|
Supported Platforms
|
|
|
|
Short Version
|
|
|
|
./configure
|
|
gmake
|
|
gmake install
|
|
adduser postgres
|
|
su - postgres
|
|
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
|
|
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 &
|
|
/usr/local/pgsql/bin/createdb test
|
|
/usr/local/pgsql/bin/psql test
|
|
|
|
The long version is the rest of this document.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Requirements
|
|
|
|
In general, a modern Unix-compatible platform should be able to run
|
|
PostgreSQL. The platforms that had received explicit testing at the time of
|
|
release are listed in the section called Supported Platforms below. In the
|
|
doc subdirectory of the distribution there are several platform-specific FAQ
|
|
documents you might wish to consult if you are having trouble.
|
|
|
|
Compiler. You need a Standard ("ANSI") C compiler. Recent versions of GCC
|
|
are recommendable, but PostgreSQL is known to build with a wide variety of
|
|
compilers from different vendors.
|
|
|
|
Make. Building PostgreSQL requires GNU make; it will not work with other
|
|
make programs. GNU make is often installed under the name gmake. This
|
|
document will always refer to it by that name. (On GNU/Linux systems GNU
|
|
make is the default tool with the name make.) To test for GNU make enter
|
|
|
|
gmake --version
|
|
|
|
If at all possible you should try to use version 3.76.1 or later. If you
|
|
need to get GNU make, you can find it at your local GNU mirror site (see
|
|
http://www.gnu.org/order/ftp.html) or at ftp://ftp.gnu.org/gnu/make.
|
|
|
|
Resources. Check that you have sufficient disk space. You will need about 30
|
|
MB for the source tree during compilation and about 5 MB for the
|
|
installation directory. An empty database takes about 1 MB, later it takes
|
|
about five times the amount of space that a flat text file with the same
|
|
data would take. If you are going to run the regression tests you will
|
|
temporarily need an extra 20 MB. Use the df command to check for disk space.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
If You Are Upgrading
|
|
|
|
The internal data storage format changes with new releases of PostgreSQL.
|
|
Therefore, if you are upgrading an existing installation that does not have
|
|
a version number "7.1.x", you must back up and restore your data as shown
|
|
here. These instructions assume that your existing installation is under the
|
|
/usr/local/pgsql directory, and that the data area is in
|
|
/usr/local/pgsql/data. Substitute your paths appropriately.
|
|
|
|
1. Make sure that your database is not updated during or after the backup.
|
|
This does not affect the integrity of the backup, but the changed data
|
|
would of course not be included. If necessary, edit the permissions in
|
|
the file /usr/local/pgsql/data/pg_hba.conf (or equivalent) to disallow
|
|
access from everyone except you.
|
|
|
|
2. To dump your database installation, type:
|
|
|
|
pg_dumpall > outputfile
|
|
|
|
If you need to preserve the oids (such as when using them as foreign
|
|
keys), then use the -o option when running pg_dumpall.
|
|
|
|
Make sure that you use the pg_dumpall command from the version you are
|
|
currently running. 7.1's pg_dumpall should not be used on older
|
|
databases.
|
|
|
|
3. If you are installing the new version at the same location as the old
|
|
one then shut down the old server, at the latest before you install the
|
|
new files:
|
|
|
|
kill -INT `cat /usr/local/pgsql/data/postmaster.pid`
|
|
|
|
Versions prior to 7.0 do not have this postmaster.pid file. If you are
|
|
using such a version you must find out the process id of the server
|
|
yourself, for example by typing ps ax | grep postmaster, and supply it
|
|
to the kill command.
|
|
|
|
On systems which have PostgreSQL started at boot time, there is
|
|
probably a startup file that will accomplish the same thing. For
|
|
example, on a Redhat Linux system one might find that
|
|
|
|
/etc/rc.d/init.d/postgres.init stop
|
|
|
|
works.
|
|
|
|
4. If you are installing in the same place as the old version then it is
|
|
also a good idea to move the old installation out of the way, in case
|
|
you still need it later on. Use a command like this:
|
|
|
|
mv /usr/local/pgsql /usr/local/pgsql.old
|
|
|
|
After you have installed PostgreSQL 7.1, create a new database directory and
|
|
start the new server. Remember that you must execute these commands while
|
|
logged in to the special database user account (which you already have if
|
|
you are upgrading).
|
|
|
|
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/bin
|
|
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/bin
|
|
|
|
Finally, restore your data with
|
|
|
|
/usr/local/pgsql/bin/psql -d template1 -f outputfile
|
|
|
|
using the new psql.
|
|
|
|
You can also install the new version in parallel with the old one to
|
|
decrease the downtime. These topic are discussed at length in the
|
|
Administrator's Guide, which you are encouraged to read in any case. The
|
|
pg_upgrade utility can also often be used.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Installation Procedure
|
|
|
|
1. Configuration
|
|
|
|
The first step of the installation procedure to configure the source
|
|
tree for your system and choose the options you would like. This is
|
|
done by running the configure script. For a default installation,
|
|
simply type
|
|
|
|
./configure
|
|
|
|
This script will run a number of tests to guess values for various
|
|
system dependent variables and detect some quirks of your operating
|
|
system, and finally creates several files in the build tree to record
|
|
what it found.
|
|
|
|
The default configuration will build the server and utilities, as well
|
|
as all client applications and interfaces that only require a C
|
|
compiler. All files will be installed under /usr/local/pgsql by
|
|
default.
|
|
|
|
You can customize the build and installation process by giving one or
|
|
more of the following command line options to configure:
|
|
|
|
--prefix=PREFIX
|
|
|
|
Install all files under the directory PREFIX instead of
|
|
/usr/local/pgsql. The actual files will be installed into various
|
|
subdirectories; no files will ever be installed directly into the
|
|
PREFIX directory.
|
|
|
|
If you have special needs, you can also customize the individual
|
|
subdirectories with the following options.
|
|
|
|
--exec-prefix=EXEC-PREFIX
|
|
|
|
You can install architecture-dependent files under a different
|
|
prefix, EXEC-PREFIX, than what PREFIX was set to. This can be
|
|
useful to share architecture-independent files between hosts. If
|
|
you omit this, then EXEC-PREFIX is set equal to PREFIX and both
|
|
architecture dependent and independent files will be installed
|
|
under the same tree, which is probably what you want.
|
|
|
|
--bindir=DIRECTORY
|
|
|
|
Specifies the directory for executable programs. The default is
|
|
EXEC-PREFIX/bin, which normally means /usr/local/pgsql/bin.
|
|
|
|
--datadir=DIRECTORY
|
|
|
|
Sets the directory for read-only data files used by the installed
|
|
programs. The default is PREFIX/share. Note that this has nothing
|
|
to do with where your database files will be placed.
|
|
|
|
--sysconfdir=DIRECTORY
|
|
|
|
The directory for various configuration files, PREFIX/etc by
|
|
default.
|
|
|
|
--libdir=DIRECTORY
|
|
|
|
The location to install libraries and dynamically loadable
|
|
modules. The default is EXEC-PREFIX/lib.
|
|
|
|
--includedir=DIRECTORY
|
|
|
|
The directory for installing C and C++ header files. The default
|
|
is PREFIX/include.
|
|
|
|
--docdir=DIRECTORY
|
|
|
|
Documentation files, except "man" pages, will be installed into
|
|
this directory. The default is PREFIX/doc.
|
|
|
|
--mandir=DIRECTORY
|
|
|
|
The man pages that come with PostgreSQL will be installed under
|
|
this directory, in their respective manx subdirectories.
|
|
PREFIX/man.
|
|
|
|
--with-includes=DIRECTORIES
|
|
|
|
DIRECTORIES is a colon-separated list of directories that will be
|
|
added to the list the compiler searches for header files. If you
|
|
have optional packages (such as GNU Readline) installed in a
|
|
non-standard location you have to use this option and probably the
|
|
corresponding --with-libraries option.
|
|
|
|
Example: --with-includes=/opt/gnu/include:/usr/sup/include.
|
|
|
|
--with-libraries=DIRECTORIES
|
|
|
|
DIRECTORIES is a colon-separated list of directories to search for
|
|
libraries. You will probably have to use this option (and the
|
|
corresponding --with-includes option) if you have packages
|
|
installed in non-standard locations.
|
|
|
|
Example: --with-libraries=/opt/gnu/lib:/usr/sup/lib.
|
|
|
|
--enable-locale
|
|
|
|
Enables locale support. There is a performance penalty associated
|
|
with locale support, but if you are not in an English-speaking
|
|
environment you will most likely need this.
|
|
|
|
--enable-recode
|
|
|
|
Enables character set recode support. See doc/README.Charsets for
|
|
details on this feature.
|
|
|
|
--enable-multibyte
|
|
|
|
Allows the use of multibyte character encodings. This is primarily
|
|
for languages like Japanese, Korean, and Chinese. Read
|
|
doc/README.mb for details.
|
|
|
|
--with-pgport=NUMBER
|
|
|
|
Set NUMBER as the default port number for server and clients. The
|
|
default is 5432. The port can always be changed later on, but if
|
|
you specify it here then both server and clients will have the
|
|
same default compiled in, which can be very convenient.
|
|
|
|
--with-CXX
|
|
|
|
Build the C++ interface library. configure will automatically pick
|
|
the C++ compiler that goes with the C compiler you are using. It
|
|
is not recommended or supported to use C and C++ compilers of
|
|
different origin in the same build.
|
|
|
|
--with-perl
|
|
|
|
Build the Perl interface module. The Perl interface will be
|
|
installed at the usual place for Perl modules (typically under
|
|
/usr/lib/perl), so you must have root access to perform the
|
|
installation step (see step 4). You need to have Perl 5 installed
|
|
to use this option.
|
|
|
|
--with-python
|
|
|
|
Build the Python interface module. You need to have root access to
|
|
be able to install the Python module at its default place
|
|
(/usr/lib/pythonx.y). To be able to use this option, you must have
|
|
Python installed and your system needs to support shared
|
|
libraries. If you instead want to build a new complete interpreter
|
|
binary, you will have to do it manually.
|
|
|
|
--with-tcl
|
|
|
|
Builds components that require Tcl, which are libpgtcl, pgtclsh,
|
|
and PL/Tcl.
|
|
|
|
--with-x
|
|
|
|
Use the X Window System. If you specified --with-tcl then this
|
|
will enable the build of modules requiring Tcl/Tk, that is, pgtksh
|
|
and pgaccess.
|
|
|
|
--with-tclconfig=DIRECTORY, --with-tkconfig=DIRECTORY
|
|
|
|
Tcl/Tk installs the files tclConfig.sh and tkConfig.sh which
|
|
contain certain configuration information that is needed to build
|
|
modules interfacing to Tcl or Tk. These files are normally found
|
|
automatically at their well-known location, but if you want to use
|
|
a different version of Tcl or Tk you can specify the directory
|
|
where to find them.
|
|
|
|
--enable-odbc
|
|
|
|
Build the ODBC driver package.
|
|
|
|
--with-odbcinst=DIRECTORY
|
|
|
|
Specifies the directory where the ODBC driver will expect its
|
|
odbcinst.ini configuration file. The default is
|
|
/usr/local/pgsql/etc or whatever you specified as --sysconfdir. A
|
|
default file will be installed there.
|
|
|
|
--with-krb4=DIRECTORY, --with-krb5=DIRECTORY
|
|
|
|
Build with suppport for Kerberos authentication. You can use
|
|
either Kerberos version 4 or 5, but not both. The DIRECTORY
|
|
argument specifies the root directory of the Kerberos
|
|
installation; /usr/athena is assumed as default. If the relevant
|
|
headers files and libraries are not under a common parent
|
|
directory, then you must use the --with-includes and
|
|
--with-libraries options in addition to this option. If, on the
|
|
other hand, the required files are in a location that is searched
|
|
by default (e.g., /usr/lib), then you can leave off the argument.
|
|
|
|
configure will check for the required header files and libraries
|
|
to make sure that your Kerberos installation is sufficient before
|
|
proceeding.
|
|
|
|
--with-krb-srvnam=NAME
|
|
|
|
The name of the Kerberos service principal. "postgres" is the
|
|
default. There's probably no reason to change this.
|
|
|
|
--with-krb-srvtab=FILE
|
|
|
|
Specifies the location of the Kerberos server shared key file
|
|
("srvtab"). If you are using Kerberos 4, this defaults to
|
|
/etc/srvtab, with Kerberos 5 to
|
|
FILE:/usr/local/pgsql/etc/krb5.keytab, or equivalent, depending on
|
|
what you set --sysconfdir to above.
|
|
|
|
--enable-syslog
|
|
|
|
Enables the PostgreSQL server to use the syslog logging facility.
|
|
(Using this option does not mean that you have to log with syslog
|
|
or even that it will be done by default, it simply makes it
|
|
possible to turn this option on at run time.)
|
|
|
|
--enable-debug
|
|
|
|
Compiles all programs and libraries with debugging symbols. This
|
|
means that you can run the programs through a debugger to analyze
|
|
problems. This option is not recommended for production use.
|
|
|
|
Environment variables. You can set the CC environment variable to
|
|
choose the C compiler to use. If you don't then configure will look for
|
|
one. For example:
|
|
|
|
CC=/opt/bin/gcc ./configure
|
|
|
|
2. Build
|
|
|
|
To start the build, type
|
|
|
|
gmake
|
|
|
|
(Remember to use GNU make.) The build can take anywhere from 5 minutes
|
|
to half an hour. The last line displayed should be
|
|
|
|
All of PostgreSQL is successfully made. Ready to install.
|
|
|
|
3. Regression Tests
|
|
|
|
If you want to test the newly built server before you install it, you
|
|
can run the regression tests at this point. The regression tests are a
|
|
test suite to verify that PostgreSQL runs on your machine in the way
|
|
the developers expected it to. Type
|
|
|
|
gmake -C src/test/regress all runcheck
|
|
|
|
It is possible that some tests fail, due to differences in error
|
|
message wording or floating point results. The file
|
|
src/test/regress/README and the Administrator's Guide contain detailed
|
|
information about interpreting the test results. You can repeat this
|
|
test at any later time by issuing the same command.
|
|
|
|
4. Installing The Files
|
|
|
|
Note: If you are upgrading an existing system and are going
|
|
to install the new files over the old ones then you should
|
|
have backed up your data and shut down the old server by now,
|
|
as explained in the section called If You Are Upgrading
|
|
above.
|
|
|
|
To install PostgreSQL enter
|
|
|
|
gmake install
|
|
|
|
This will install files into the directories that were specified in
|
|
step 1. Make sure that you have appropriate permissions to write into
|
|
that area. Normally you need to do this step as root. Alternatively,
|
|
you could create the target directories in advance and arrange for
|
|
appropriate permissions to be granted.
|
|
|
|
If you built the Perl or Python interfaces and you were not the root
|
|
user when you executed the above command then that part of the
|
|
installation probably failed. In that case you should become the root
|
|
user and then do
|
|
|
|
gmake -C src/interfaces/perl5 install
|
|
gmake -C src/interfaces/python install
|
|
|
|
Due to a quirk in the Perl build environment the first command will
|
|
actually rebuild the complete interface and then install it. This is
|
|
not harmful, just unusual. If you do not have superuser access you are
|
|
on your own: you can still take the required files and place them in
|
|
other directories where Perl or Python can find them, but how to do
|
|
that is left as an exercise.
|
|
|
|
Client-only installation. If you want to install only the client
|
|
applications and interfaces, then you can use these commands:
|
|
|
|
gmake -C src/bin install
|
|
gmake -C src/interfaces install
|
|
gmake -C doc install
|
|
|
|
To undo the installation use the command gmake uninstall. However, this
|
|
will not remove the Perl and Python interfaces and it will not remove
|
|
any directories.
|
|
|
|
Cleanup. After the installation you can make room by removing the built
|
|
files from the source tree with the gmake clean command. This will preserve
|
|
the choices made by the configure program, so that you can rebuild
|
|
everything with gmake later on. To reset the source tree to the state in
|
|
which it was distributed, use gmake distclean. If you are going to build for
|
|
several platforms from the same source tree you must do this and
|
|
re-configure for each build.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Post-Installation Setup
|
|
|
|
Shared Libraries
|
|
|
|
On most systems that have shared libraries (which most systems do) you need
|
|
to tell your system how to find the newly installed shared libraries. How to
|
|
do this varies between platforms, but the most widely usable method is to
|
|
set the environment variable LD_LIBRARY_PATH like so: In Bourne shells (sh,
|
|
ksh, bash, zsh)
|
|
|
|
LD_LIBRARY_PATH=/usr/local/pgsql/lib
|
|
export LD_LIBRARY_PATH
|
|
|
|
or in csh or tcsh
|
|
|
|
setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
|
|
|
|
Replace /usr/local/pgsql/lib with whatever you set --libdir to in step 1.
|
|
You should put these commands into a shell startup file such as /etc/profile
|
|
or ~/.bash_profile.
|
|
|
|
On Linux systems the following is the preferred method, but you must have
|
|
root access. Edit the file /etc/ld.so.conf to add a line
|
|
|
|
/usr/local/pgsql/lib
|
|
|
|
Then run command /sbin/ldconfig.
|
|
|
|
If in doubt, refer to the manual pages of your system. If you later on get a
|
|
message like
|
|
|
|
psql: error in loading shared libraries
|
|
libpq.so.2.1: cannot open shared object file: No such file or directory
|
|
|
|
then this step was necessary. Simply take care of it then.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Environment Variables
|
|
|
|
If you installed into /usr/local/pgsql or some other location that is not
|
|
searched for programs by default, you need to add /usr/local/pgsql/bin (or
|
|
what you set --bindir to in step 1) into your PATH. To do this, add the
|
|
following to your shell startup file, such as ~/.bash_profile (or
|
|
/etc/profile, if you want it to affect every user):
|
|
|
|
PATH=$PATH:/usr/local/pgsql/bin
|
|
|
|
If you are using csh or tcsh, then use this command:
|
|
|
|
set path = ( /usr/local/pgsql/bin path )
|
|
|
|
To enable your system to find the man documentation, you need to add a line
|
|
like the following to a shell startup file:
|
|
|
|
MANPATH=$MANPATH:/usr/local/pgsql/man
|
|
|
|
The environment variables PGHOST and PGPORT specify to client applications
|
|
the host and port of the database server, overriding the compiled-in
|
|
defaults. If you are going to run client applications remotely then it is
|
|
convenient if every user that plans to use the database sets PGHOST, but it
|
|
is not required and the settings can be communicated via command line
|
|
options to most client programs.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Getting Started
|
|
|
|
The following is a quick summary of how to get PostgreSQL up and running
|
|
once installed. The Administrator's Guide contains more information.
|
|
|
|
1. Create the PostgreSQL server account. This is the user the server will
|
|
run as. For production use you should create a separate, unprivileged
|
|
account ("postgres" is commonly used). If you do not have root access
|
|
or just want to play around, your own user account is enough, but
|
|
running the server as root is a security risk and therefore not
|
|
allowed.
|
|
|
|
adduser postgres
|
|
|
|
2. Create a database installation with the initdb command. To run initdb
|
|
you must be logged in to your PostgreSQL server account. It will not
|
|
work as root.
|
|
|
|
root# mkdir /usr/local/pgsql/data
|
|
root# chown postgres /usr/local/pgsql/data
|
|
root# su - postgres
|
|
postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
|
|
|
|
The -D option specifies the location where the data will be stored. You
|
|
can use any path you want, it does not have to be under the
|
|
installation directory. Just make sure that the server account can
|
|
write to the directory (or create it, if it doesn't already exist)
|
|
before starting initdb, as illustrated here.
|
|
|
|
3. The previous step should have told you how to start up the database
|
|
server. Do so now. The command should look something like
|
|
|
|
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
|
|
|
|
This will start the server in the foreground. To put the server in the
|
|
background use something like
|
|
|
|
nohup /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data \
|
|
</dev/null >>server.log 2>&1 </dev/null &
|
|
|
|
To stop a server running in the background you can type
|
|
|
|
kill `cat /usr/local/psgql/data/postmaster.pid`
|
|
|
|
In order to allow TCP/IP connections (rather than only Unix domain
|
|
socket ones) you need to pass the -i option to postmaster.
|
|
|
|
4. Create a database:
|
|
|
|
createdb testdb
|
|
|
|
Then enter
|
|
|
|
psql testdb
|
|
|
|
to connect to that database. At the prompt you can enter SQL commands
|
|
and start experimenting.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
What Now?
|
|
|
|
* The Tutorial should be your first reading if you are completely new to
|
|
SQL databases. It should have been installed at
|
|
/usr/local/pgsql/doc/tutorial/index.html unless you changed the
|
|
installation directories.
|
|
|
|
* If you are familiar with database concepts then you want to proceed
|
|
with the Administrator's Guide, which contains information about how to
|
|
set up the database server, database users, and authentication. It can
|
|
be found at /usr/local/pgsql/doc/admin/index.html.
|
|
|
|
* Usually, you will want to modify your computer so that it will
|
|
automatically start the database server whenever it boots. Some
|
|
suggestions for this are in the Administrator's Guide.
|
|
|
|
* Run the regression tests against the installed server (using the
|
|
sequential test method). If you didn't run the tests before
|
|
installation, you should definitely do it now. This is also explained
|
|
in the Administrator's Guide.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Supported Platforms
|
|
|
|
At the time of release, PostgreSQL 7.1 has been verified by the developer
|
|
community to work on the following platforms. A supported platform generally
|
|
means that PostgreSQL builds and installs according to these instructions
|
|
and that the regression tests pass, except for minor differences.
|
|
|
|
Note: If you are having problems with the installation on a
|
|
supported platform, please write to <pgsql-bugs@postgresql.org> or
|
|
<pgsql-ports@postgresql.org>, not to the people listed here.
|
|
|
|
OS Processor Version Reported Remarks
|
|
AIX 4.3.2 RS6000 7.0 2000-04-05, Andread Zeugswetter See also
|
|
(<Andreas.Zeugswetter@telecom.at>) doc/FAQ_AIX
|
|
BSDI 4.01 x86 7.0 2000-04-04, Bruce Momjian
|
|
(<pgman@candle.pha.pa.us>)
|
|
Compaq Tru64 Alpha 7.0 2000-04-11, Andrew McMurry
|
|
5.0 (<andrew.mcmurry@astro.uio.no>)
|
|
FreeBSD 4.0 x86 7.0 2000-04-04, Marc Fournier
|
|
(<scrappy@hub.org>)
|
|
HPUX 9.0x andPA-RISC 7.0 2000-04-12, Tom Lane
|
|
10.20 (<tgl@sss.pgh.pa.us>)
|
|
IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley MIPSPro
|
|
(<hxpro@cinesite.co.uk>) 7.3.1.1m N32
|
|
build
|
|
Linux 2.0.x Alpha 7.0 2000-04-05, Ryan Kirkpatrick with published
|
|
(<pgsql@rkirkpat.net>) patches
|
|
Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Regression
|
|
(<segfault@hardline.org>) test needs
|
|
work.
|
|
Linux 2.2.x x86 7.0 2000-03-26, Lamar Owen
|
|
(<lamar.owen@wgcr.org>)
|
|
Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii Cobalt Qube
|
|
(<t-ishii@sra.co.jp>)
|
|
Linux 2.2.5 Sparc 7.0 2000-04-02, Tom Szybist
|
|
(<szybist@boxhill.com>)
|
|
LinuxPPC R4 PPC603e 7.0 2000-04-13, Tatsuo Ishii
|
|
(<t-ishii@sra.co.jp>)
|
|
mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
|
|
(<t-ishii@sra.co.jp>)
|
|
NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche
|
|
(<prlw1@newn.cam.ac.uk>)
|
|
NetBSD 1.4U x86 7.0 2000-03-26, Patrick Welche
|
|
(<prlw1@newn.cam.ac.uk>)
|
|
NetBSD m68k 7.0 2000-04-10, Henry B. Hotz Mac 8xx
|
|
(<hotz@jpl.nasa.gov>)
|
|
NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
|
|
(<tih@kpnQwest.no>)
|
|
QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos
|
|
(<kardos@repas-aeg.de>)
|
|
SCO x86 6.5 1999-05-25, Andrew Merrill
|
|
OpenServer 5 (<andrew@compclass.com>)
|
|
SCO UnixWare x86 7.0 2000-04-18, Billy G. Allie See also
|
|
7 (<Bill.Allie@mug.org>) doc/FAQ_SCO
|
|
Solaris x86 7.0 2000-04-12, Marc Fournier
|
|
(<scrappy@hub.org>)
|
|
Solaris Sparc 7.0 2000-04-12, Peter Eisentraut
|
|
2.5.1-2.7 (<peter_e@gmx.net>), Marc Fournier
|
|
(<scrappy@hub.org>)
|
|
SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii
|
|
(<t-ishii@sra.co.jp>)
|
|
Windows/Win32x86 7.0 2000-04-02, Magnus Hagander Client-side
|
|
(<mha@sollentuna.net>) libraries or
|
|
ODBC/JDBC, no
|
|
server-side
|
|
WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak with
|
|
(<horak@sit.plzen-city.cz>) RedHat/Cygnus
|
|
Cygwin toolset
|
|
|
|
Unsupported Platforms. The following platforms have not been verified to
|
|
work. Platforms listed for version 6.3.x and later should also work with
|
|
7.1, but we did not receive explicit confirmation of such at the time this
|
|
list was compiled. We include these here to let you know that these
|
|
platforms could be supported if given some attention.
|
|
|
|
OS Processor Version Reported Remarks
|
|
BeOS x86 7.0 2000-05-01, Adam Haberlach Client-side
|
|
(<adam@newsnipple.com>) coming soon?
|
|
DGUX m88k 6.3 1998-03-01, Brian E Gallew 6.4 probably
|
|
5.4R4.11 (<geek+@cmu.edu>) OK. Needs new
|
|
maintainer.
|
|
NetBSD 1.3VAX 6.3 1998-03-01, Tom I Helbekkmo 7.0 should
|
|
(<tih@kpnQwest.no>) work.
|
|
System V m88k 6.2.1 1998-03-01, Doug Winterburn Needs new TAS
|
|
R4 4.4 (<dlw@seavme.xroads.com>) spinlock code
|
|
System V MIPS 6.4 1998-10-28, Frank Ridderbusch No 64-bit
|
|
R4 (<ridderbusch.pad@sni.de>) integer
|
|
Ultrix MIPS, VAX 6.x 1998-03-01 No recent
|
|
reports.
|
|
Obsolete?
|
|
MacOS all 6.x 1998-03-01 Not library
|
|
compatible;
|
|
use ODBC/JDBC.
|
|
NextStep x86 6.x 1998-03-01, David Wetzel Client-only
|
|
(<dave@turbocat.de>) support
|