バージョンごとのドキュメント一覧

17.4. インストール手順

<title>Installation Procedure</title>
  1. <title>Configuration</title>

    構成

    The first step of the installation procedure is to configure the source tree for your system and choose the options you would like. This is done by running the <filename>configure</filename> script. For a default installation simply enter: インストール手順の最初のステップは、システムに合わせてソースツリーを設定し、使用するオプションを選択することです。 configureスクリプトを実行することでこれを行います。 デフォルトのインストールを行う場合は、単に以下を入力してください。

    ./configure
    

    This script will run a number of tests to determine values for various system dependent variables and detect any quirks of your operating system, and finally will create several files in the build tree to record what it found. このスクリプトは、各種のシステムに依存した変数の値を決定するために多くの試験を行い、使用中のオペレーティングシステムが持つどんなクセでも検出し、最終的に構築用ツリーに結果を記録するためのファイルをいくつか作成します。

    You can also run <filename>configure</filename> in a directory outside the source tree, and then build there, if you want to keep the build directory separate from the original source files. This procedure is called a <indexterm><primary>VPATH</primary></indexterm><firstterm>VPATH</firstterm> build. Here's how: 構築用のディレクトリを別の場所にしたい場合は、ソースツリーの外のディレクトリでconfigureを実行することもできます。 この処理はVPATH構築と呼ばれます。 どのように行うかは下記を参照して下さい。

    mkdir build_dir
    cd build_dir
    
    <userinput>/path/to/source/tree/configure [options go here]</userinput>
    
    /path/to/source/tree/configure [オプションはここに]
    make
    

    The default configuration will build the server and utilities, as well as all client applications and interfaces that require only a C compiler. All files will be installed under <filename>/usr/local/pgsql</filename> by default. デフォルトの構成では、サーバ、ユーティリティの他に、Cコンパイラだけを必要とするクライアントアプリケーションやインタフェースを構築します。 デフォルトでは、全てのファイルは/usr/local/pgsql以下にインストールされます。

    You can customize the build and installation process by supplying one or more command line options to <filename>configure</filename>. Typically you would customize the install location, or the set of optional features that are built. <filename>configure</filename> has a large number of options, which are described in <xref linkend="configure-options"/>. configureにコマンドラインオプションを1つ以上指定することで、構築処理やインストール処理を変更することができます。 よくあるのは、インストールの位置や構築するオプションの機能の設定を変更することでしょう。 configureには数多くのオプションがあり、それは17.4.1に書かれています。

    Also, <filename>configure</filename> responds to certain environment variables, as described in <xref linkend="configure-envvars"/>. These provide additional ways to customize the configuration. また、configureは、17.4.2に書かれているように特定の環境変数に対応しています。 これは設定を変更する追加の方法を提供します。

  2. <title>Build</title>

    構築

    To start the build, type either of: 構築作業を開始するには、以下のいずれかを入力してください。

    make
    make all
    

    (Remember to use <acronym>GNU</acronym> <application>make</application>.) The build will take a few minutes depending on your hardware. GNU makeを使用することを忘れないでください。) ハードウェアに依存しますが、構築作業には数分かかります。

    If you want to build everything that can be built, including the documentation (HTML and man pages), and the additional modules (<filename>contrib</filename>), type instead: もし、ドキュメント(HTMLやman)や追加モジュール(contrib)を含め、構築可能なものすべてを構築したい場合、次のように入力します。

    make world
    

    If you want to build everything that can be built, including the additional modules (<filename>contrib</filename>), but without the documentation, type instead: もし、追加モジュール(contrib)は含めるがドキュメントは含めずに、構築可能なものすべてを構築したい場合、次のように入力します。

    make world-bin
    

    If you want to invoke the build from another makefile rather than manually, you must unset <varname>MAKELEVEL</varname> or set it to zero, for instance like this: 手動で指定するのではなく、別のMakefileから構築をしたい場合には、例えば以下のようにMAKELEVELを削除するか、0に設定しなければなりません。

    build-postgresql:
            $(MAKE) -C postgresql MAKELEVEL=0 all
    

    Failure to do that can lead to strange error messages, typically about missing header files. 上記に失敗すると、通常はヘッダファイルが見つからないという奇妙なエラーメッセージが出る場合があります。

  3. <title>Regression Tests</title>

    リグレッションテスト

    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 <productname>PostgreSQL</productname> runs on your machine in the way the developers expected it to. Type: インストールを行う前に、新しく構築したサーバをテストしたい場合、この時点でリグレッションテストを実行できます。 リグレッションテストとは、使用するマシンにおいてPostgreSQLが、開発者の想定通りに動作することを検証するためのテストのまとまりです。 次のように入力します。

    make check
    

    (This won't work as root; do it as an unprivileged user.) See <xref linkend="regress"/> for detailed information about interpreting the test results. You can repeat this test at any later time by issuing the same command. (これは root では動作しません。 非特権ユーザとして実行してください。) 第33章にはテスト結果の解釈に関する詳しい情報があります。 同じコマンドを入力することで、後にいつでもテストを繰り返すことができます。

  4. <title>Installing the Files</title>

    ファイルのインストール

    注記

    If you are upgrading an existing system be sure to read <xref linkend="upgrading"/>, which has instructions about upgrading a cluster. もし既存のシステムのアップグレードをする場合、DBクラスタのアップグレードの解説が記載されている19.6を参照してください。

    To install <productname>PostgreSQL</productname> enter: PostgreSQLをインストールするには、以下を入力してください。

    make install
    

    This will install files into the directories that were specified in <xref linkend="configure"/>. Make sure that you have appropriate permissions to write into that area. Normally you need to do this step as root. Alternatively, you can create the target directories in advance and arrange for appropriate permissions to be granted. これは、ファイルをステップ 1で指定されたディレクトリにインストールします。 その領域に書き込むための権限を持っていることを確認してください。 通常はこのステップはrootで行う必要があります。 代わりに対象とするディレクトリを前もって作成し、適切に権限を調整することも可能です。

    To install the documentation (HTML and man pages), enter: ドキュメント(HTMLやman)をインストールするには、以下を入力して下さい。

    make install-docs
    

    If you built the world above, type instead: 上記のようにすべてを(worldを付けて)構築していた場合には、代わりに以下を入力してください。

    make install-world
    

    This also installs the documentation. これによりドキュメントもインストールされます。

    If you built the world without the documentation above, type instead: 上記のようにドキュメントを除くすべてを構築していた場合には、代わりに以下を入力してください。

    make install-world-bin
    

    You can use <literal>make install-strip</literal> instead of <literal>make install</literal> to strip the executable files and libraries as they are installed. This will save some space. If you built with debugging support, stripping will effectively remove the debugging support, so it should only be done if debugging is no longer needed. <literal>install-strip</literal> tries to do a reasonable job saving space, but it does not have perfect knowledge of how to strip every unneeded byte from an executable file, so if you want to save all the disk space you possibly can, you will have to do manual work. make installの代わりにmake install-stripを使用することで、インストール時に実行可能ファイルやライブラリをストリップ(strip)することができます。 これにより、多少の容量を節約できます。 デバッグをサポートするように構築している場合でも、ストリップするとデバッグのサポートは実質、除去されてしまいます。 したがって、これはデバッグが必要なくなった場合にのみ実行すべきです。 install-stripは容量を節約するために適切な作業を行おうとしますが、実行可能ファイルから全ての不必要なバイトを完全にストリップすることはできません。 可能な限りのディスク容量をすべて節約したい場合は、手動で作業を行う必要があります。

    The standard installation provides all the header files needed for client application development as well as for server-side program development, such as custom functions or data types written in C. この標準的なインストール方法では、クライアントアプリケーションの開発に必要なヘッダファイルと、Cで独自の関数やデータ型を作成するといったサーバ側のプログラムの開発用のヘッダファイルが用意されます。

    <title>Client-only installation:</title> クライアント側のみのインストール:  If you want to install only the client applications and interface libraries, then you can use these commands: クライアントアプリケーションとインタフェースライブラリのみをインストールしたい場合、下記のコマンドを使います。

    make -C src/bin install
    make -C src/include install
    make -C src/interfaces install
    make -C doc install
    

    <filename>src/bin</filename> has a few binaries for server-only use, but they are small. src/binにはサーバ用の数個のバイナリがあります。これらは小さなものです。

<title>Uninstallation:</title> アンインストール:  To undo the installation use the command <command>make uninstall</command>. However, this will not remove any created directories. インストールを取り消すには、make uninstall コマンドを使います。 しかし、作成済みのディレクトリは削除されません。

<title>Cleaning:</title> クリーニング:  After the installation you can free disk space by removing the built files from the source tree with the command <command>make clean</command>. This will preserve the files made by the <command>configure</command> program, so that you can rebuild everything with <command>make</command> later on. To reset the source tree to the state in which it was distributed, use <command>make distclean</command>. If you are going to build for several platforms within the same source tree you must do this and re-configure for each platform. (Alternatively, use a separate build tree for each platform, so that the source tree remains unmodified.) インストールが終わったら、make clean コマンドを使ってソースツリーから構築用のファイルを削除し、ディスク領域を解放できます。 configureプログラムが作るファイルは保持されますので、後でmakeコマンドですべてを再構築できます。 ソースツリーを配布された時の状態に戻したい場合は、make distcleanコマンドを使います。 同じソースツリー内で複数のプラットフォーム向けに構築する場合、これを実行して、それぞれのプラットフォームに対し再構成しなければなりません。 (または、未変更のソースツリーを維持するために、各プラットフォームで別々の構築用ツリーを使用してください。)

If you perform a build and then discover that your <command>configure</command> options were wrong, or if you change anything that <command>configure</command> investigates (for example, software upgrades), then it's a good idea to do <command>make distclean</command> before reconfiguring and rebuilding. Without this, your changes in configuration choices might not propagate everywhere they need to. 構築作業を行った後でconfigure用オプションが間違っていることに気付いた場合や、configureの調査結果に何らかの変更を加えた場合(例えば、ソフトウェアのアップグレードなど)、再設定と再構築の前にmake distcleanを行うことをお勧めします。 さもないと、設定選択肢の変更は、必要なところ全てには反映されない可能性があります。

17.4.1. configureオプション

<title><filename>configure</filename> Options</title>

<command>configure</command>'s command line options are explained below. This list is not exhaustive (use <literal>./configure &#45;-help</literal> to get one that is). The options not covered here are meant for advanced use-cases such as cross-compilation, and are documented in the standard Autoconf documentation. configureのコマンドラインオプションを以下で説明します。 この一覧は完全なものではありません(完全なものを得るには./configure --helpを使ってください)。 ここで取り上げていないオプションは黒須コンパイルのような高度なユースケースのためのもので、標準のAutoconfのドキュメントに書かれています。

17.4.1.1. インストレーションの位置

<title>Installation Locations</title>

These options control where <literal>make install</literal> will put the files. The <option>&#45;-prefix</option> option is sufficient for most cases. If you have special needs, you can customize the installation subdirectories with the other options described in this section. Beware however that changing the relative locations of the different subdirectories may render the installation non-relocatable, meaning you won't be able to move it after installation. (The <literal>man</literal> and <literal>doc</literal> locations are not affected by this restriction.) For relocatable installs, you might want to use the <literal>&#45;-disable-rpath</literal> option described later. このオプションはmake installがファイルをどこに置くかを制御します。 たいていの場合--prefixオプションで十分です。 特別な必要性があるのであれば、この節に書かれた他のオプションを使用して個々のインストレーションサブディレクトリを変更できます。 しかし、異なるサブディレクトリの相対的な位置を変更した場合、インストレーションは再配置不能になります。つまり、インストールの後にディレクトリを移動できないことに注意してください。 (mandocの場所はこの制限の影響を受けません。) 再配置可能インストールのために、後述の--disable-rpathを使用しようと考えるかもしれません。

--prefix=PREFIX

Install all files under the directory <replaceable>PREFIX</replaceable> instead of <filename>/usr/local/pgsql</filename>. The actual files will be installed into various subdirectories; no files will ever be installed directly into the <replaceable>PREFIX</replaceable> directory. /usr/local/pgsqlではなく、PREFIXディレクトリ以下に全てのファイルをインストールします。 ファイルは実際には様々なサブディレクトリにインストールされ、PREFIXディレクトリの直下にインストールされるファイルはありません。

--exec-prefix=EXEC-PREFIX

You can install architecture-dependent files under a different prefix, <replaceable>EXEC-PREFIX</replaceable>, than what <replaceable>PREFIX</replaceable> was set to. This can be useful to share architecture-independent files between hosts. If you omit this, then <replaceable>EXEC-PREFIX</replaceable> is set equal to <replaceable>PREFIX</replaceable> and both architecture-dependent and independent files will be installed under the same tree, which is probably what you want. アーキテクチャ依存のファイルをPREFIXの設定とは別の接頭辞EXEC-PREFIX以下にインストールすることができます。 ホスト間でアーキテクチャ非依存のファイルを共有する場合に便利です。 省略した場合、EXEC-PREFIXPREFIXと同じに設定され、アーキテクチャに依存するファイルも非依存なファイルも同じツリー以下にインストールされます。 ほとんどの場合、これが望まれています。

--bindir=DIRECTORY

Specifies the directory for executable programs. The default is <filename><replaceable>EXEC-PREFIX</replaceable>/bin</filename>, which normally means <filename>/usr/local/pgsql/bin</filename>. 実行可能プログラム用のディレクトリを指定します。 デフォルトではEXEC-PREFIX/binであり、通常/usr/local/pgsql/binとなります。

--sysconfdir=DIRECTORY

Sets the directory for various configuration files, <filename><replaceable>PREFIX</replaceable>/etc</filename> by default. 各種設定ファイル用のディレクトリを設定します。 デフォルトではPREFIX/etcです。

--libdir=DIRECTORY

Sets the location to install libraries and dynamically loadable modules. The default is <filename><replaceable>EXEC-PREFIX</replaceable>/lib</filename>. ライブラリや動的ロード可能モジュールをインストールする場所を設定します。 デフォルトはEXEC-PREFIX/libです。

--includedir=DIRECTORY

Sets the directory for installing C and C++ header files. The default is <filename><replaceable>PREFIX</replaceable>/include</filename>. CおよびC++のヘッダファイルをインストールするディレクトリを設定します。 デフォルトはPREFIX/includeです。

--datarootdir=DIRECTORY

Sets the root directory for various types of read-only data files. This only sets the default for some of the following options. The default is <filename><replaceable>PREFIX</replaceable>/share</filename>. いろいろな種類の読み取り専用データファイル用のルートディレクトリを設定します。 これは後述のオプションの一部についてのデフォルトを設定するだけです。 デフォルトはPREFIX/shareです。

--datadir=DIRECTORY

Sets the directory for read-only data files used by the installed programs. The default is <filename><replaceable>DATAROOTDIR</replaceable></filename>. Note that this has nothing to do with where your database files will be placed. インストールプログラムが使用する読み取り専用のディレクトリを設定します。 デフォルトはDATAROOTDIRです。 これはインストールするデータベースファイルがどこに設置されるかとは関係ないことを覚えておいてください。

--localedir=DIRECTORY

Sets the directory for installing locale data, in particular message translation catalog files. The default is <filename><replaceable>DATAROOTDIR</replaceable>/locale</filename>. 特にメッセージ翻訳カタログファイルのロケールデータをインストールするディレクトリを設定します。 デフォルトはDATAROOTDIR/localeです。

--mandir=DIRECTORY

The man pages that come with <productname>PostgreSQL</productname> will be installed under this directory, in their respective <filename>man<replaceable>x</replaceable></filename> subdirectories. The default is <filename><replaceable>DATAROOTDIR</replaceable>/man</filename>. PostgreSQL付属のマニュアルページがこのディレクトリ以下の、対応するmanxサブディレクトリにインストールされます。 デフォルトはDATAROOTDIR/manです。

--docdir=DIRECTORY

Sets the root directory for installing documentation files, except <quote>man</quote> pages. This only sets the default for the following options. The default value for this option is <filename><replaceable>DATAROOTDIR</replaceable>/doc/postgresql</filename>. manページを除いた、ドキュメント一式ファイルをインストールするルートディレクトリを設定します。 これは以下のオプションのデフォルトのみを設定します。 このオプションのデフォルト値はDATAROOTDIR/doc/postgresqlです。

--htmldir=DIRECTORY

The HTML-formatted documentation for <productname>PostgreSQL</productname> will be installed under this directory. The default is <filename><replaceable>DATAROOTDIR</replaceable></filename>. PostgreSQLのHTML形式化文書一式はこのディレクトリの下にインストールされます。デフォルトはDATAROOTDIRです。

注記

Care has been taken to make it possible to install <productname>PostgreSQL</productname> into shared installation locations (such as <filename>/usr/local/include</filename>) without interfering with the namespace of the rest of the system. First, the string <quote><literal>/postgresql</literal></quote> is automatically appended to <varname>datadir</varname>, <varname>sysconfdir</varname>, and <varname>docdir</varname>, unless the fully expanded directory name already contains the string <quote><literal>postgres</literal></quote> or <quote><literal>pgsql</literal></quote>. For example, if you choose <filename>/usr/local</filename> as prefix, the documentation will be installed in <filename>/usr/local/doc/postgresql</filename>, but if the prefix is <filename>/opt/postgres</filename>, then it will be in <filename>/opt/postgres/doc</filename>. The public C header files of the client interfaces are installed into <varname>includedir</varname> and are namespace-clean. The internal header files and the server header files are installed into private directories under <varname>includedir</varname>. See the documentation of each interface for information about how to access its header files. Finally, a private subdirectory will also be created, if appropriate, under <varname>libdir</varname> for dynamically loadable modules. /usr/local/includeといった)共用のインストール場所に、システムの他の名前空間に影響を与えることなくPostgreSQLをインストールすることができるような配慮がなされています。 まず、完全に展開したディレクトリ名にpostgrespgsqlという文字列が含まれていない場合、/postgresqlという文字列が自動的にdatadirsysconfdirdocdirに追加されます。 例えば、接頭辞として/usr/localを使用する場合、文書は/usr/local/doc/postgresqlにインストールされますが、接頭辞が/opt/postgresの場合は/opt/postgres/docにインストールされます。 クライアントインタフェース用の外部向けCヘッダファイルはincludedirにインストールされ、名前空間の問題はありません。 内部向けヘッダファイルやサーバ用ヘッダファイルは、includedir以下の非公開ディレクトリにインストールされます。 各インタフェース用のヘッダファイルにアクセスする方法についての情報は、そのインタフェースの文書を参照してください。 最後に、適切であれば、動的ロード可能モジュール用にlibdir以下にも非公開用のサブディレクトリが作成されます。

17.4.1.2. PostgreSQLの機能

<title><productname>PostgreSQL</productname> Features</title>

The options described in this section enable building of various <productname>PostgreSQL</productname> features that are not built by default. Most of these are non-default only because they require additional software, as described in <xref linkend="install-requirements"/>. この節に書かれたオプションは、デフォルトでは構築されないPostgreSQLの様々な機能を構築できるようにするものです。 この多くがデフォルトでないのは、17.2で書かれているように追加のソフトウェアを必要とするからだけです。

--enable-nls[=LANGUAGES]

Enables Native Language Support (<acronym>NLS</acronym>), that is, the ability to display a program's messages in a language other than English. <replaceable>LANGUAGES</replaceable> is an optional space-separated list of codes of the languages that you want supported, for example <literal>&#45;-enable-nls='de fr'</literal>. (The intersection between your list and the set of actually provided translations will be computed automatically.) If you do not specify a list, then all available translations are installed. 各国語サポート(NLS)、つまり、英語以外の言語によるプログラムメッセージの表示機能を有効にします。 LANGUAGESはオプションであり、サポートさせたい言語コードを空白で区切ったリストを指定します。例えば、--enable-nls='de fr'などとします。 (指定したリストと実際に用意された翻訳との論理積が自動的に計算されます。) リストに何も指定しなかった場合、利用可能な翻訳すべてがインストールされます。

To use this option, you will need an implementation of the <application>Gettext</application> API. このオプションを使用するためには、gettext APIの実装が必要です。

--with-perl

Build the <application>PL/Perl</application> server-side language. PL/Perlサーバサイド言語を構築します。

--with-python

Build the <application>PL/Python</application> server-side language. PL/Pythonサーバサイド言語を構築します。

--with-tcl

Build the <application>PL/Tcl</application> server-side language. PL/Tclサーバサイド言語を構築します。

--with-tclconfig=DIRECTORY

Tcl installs the file <filename>tclConfig.sh</filename>, which contains configuration information needed to build modules interfacing to Tcl. This file is normally found automatically at a well-known location, but if you want to use a different version of Tcl you can specify the directory in which to look for <filename>tclConfig.sh</filename>. Tclは、Tclへのインタフェースモジュールを構築するために必要な設定情報を含むtclConfig.shファイルをインストールします。 このファイルは通常、自動的に一般的に知られている場所にありますが、もしTclの別のバージョンを使いたい場合は、tclConfig.shを検索対象のディレクトリを指定することができます。

--with-icu

Build with support for the <productname>ICU</productname><indexterm><primary>ICU</primary></indexterm> library, enabling use of ICU collation features<phrase condition="standalone-ignore"> (see <xref linkend="collation"/>)</phrase>. This requires the <productname>ICU4C</productname> package to be installed. The minimum required version of <productname>ICU4C</productname> is currently 4.2. ICUライブラリのサポートを有効にして構築します。これによりICU照合機能が使用できるようになります。 (24.2を参照してください。) これには、ICU4Cパッケージがインストールされていることが必要です。 ICU4Cの要求される最小のバージョンは現在4.2です。

By default, <productname>pkg-config</productname><indexterm><primary>pkg-config</primary></indexterm> will be used to find the required compilation options. This is supported for <productname>ICU4C</productname> version 4.6 and later. For older versions, or if <productname>pkg-config</productname> is not available, the variables <envar>ICU_CFLAGS</envar> and <envar>ICU_LIBS</envar> can be specified to <filename>configure</filename>, like in this example: デフォルトでは、pkg-configが必要なコンパイルオプションを見つけるのに使われます。 これはICU4Cバージョン4.6またはそれ以降でサポートされています。 より古いバージョンの場合やpkg-configが使えない場合には、以下の例のように、変数ICU_CFLAGSICU_LIBSconfigureに指定できます。

./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-L/some/where/lib -licui18n -licuuc -licudata'

(If <productname>ICU4C</productname> is in the default search path for the compiler, then you still need to specify nonempty strings in order to avoid use of <productname>pkg-config</productname>, for example, <literal>ICU_CFLAGS=' '</literal>.) (ICU4Cがコンパイラのデフォルトの検索パスにあるのなら、pkg-configの使用を避けるため、例えばICU_CFLAGS=' 'のような空でない文字列を指定することも必要です。)

--with-llvm

Build with support for <productname>LLVM</productname> based <acronym>JIT</acronym> compilation<phrase condition="standalone-ignore"> (see <xref linkend="jit"/>)</phrase>. This requires the <productname>LLVM</productname> library to be installed. The minimum required version of <productname>LLVM</productname> is currently 3.9. LLVMに基づいたJITコンパイル (第32章を参照)のサポート有効にして構築します。 これには、LLVMライブラリがインストールされていることが必要です。 LLVMの要求される最小のバージョンは現在3.9です。

<command>llvm-config</command><indexterm><primary>llvm-config</primary></indexterm> will be used to find the required compilation options. <command>llvm-config</command>, and then <command>llvm-config-$major-$minor</command> for all supported versions, will be searched for in your <envar>PATH</envar>. If that would not yield the desired program, use <envar>LLVM_CONFIG</envar> to specify a path to the correct <command>llvm-config</command>. For example 要求されるコンパイルオプションを見つけるためにllvm-configが使われます。 llvm-config、それからサポートされるバージョンすべてのllvm-config-$major-$minorPATHで探します。 それで正しいバイナリが見つからなければ、正しいllvm-configへのパスを指定するためにLLVM_CONFIGを使ってください。 例えば、以下の通りです。

./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'

<productname>LLVM</productname> support requires a compatible <command>clang</command> compiler (specified, if necessary, using the <envar>CLANG</envar> environment variable), and a working C++ compiler (specified, if necessary, using the <envar>CXX</envar> environment variable). LLVMサポートはclang互換のコンパイラ(必要なら環境変数CLANGで指定してください)と動作するC++コンパイラ(必要なら環境変数CXXで指定してください)を要求します。

--with-lz4

Build with <productname>LZ4</productname> compression support. LZ4圧縮サポートを有効にして構築します。

--with-zstd

Build with <productname>Zstandard</productname> compression support. Zstandard圧縮サポートを有効にして構築します。

--with-ssl=LIBRARY

Build with support for <acronym>SSL</acronym> (encrypted) connections. The only <replaceable>LIBRARY</replaceable> supported is <option>openssl</option>. This requires the <productname>OpenSSL</productname> package to be installed. <filename>configure</filename> will check for the required header files and libraries to make sure that your <productname>OpenSSL</productname> installation is sufficient before proceeding. SSL(暗号化)接続のサポートを有効にして構築します。 サポートされている唯一のLIBRARYopensslです。 これには、OpenSSLパッケージがインストールされていることが必要です。 configureは、処理を進める前にOpenSSLのインストールを確認するために、必要なヘッダファイルとライブラリを検査します。

--with-openssl

Obsolete equivalent of <literal>&#45;-with-ssl=openssl</literal>. --with-ssl=opensslに相当する古いものです。

--with-gssapi

Build with support for GSSAPI authentication. On many systems, the GSSAPI system (usually a part of the Kerberos installation) is not installed in a location that is searched by default (e.g., <filename>/usr/include</filename>, <filename>/usr/lib</filename>), so you must use the options <option>&#45;-with-includes</option> and <option>&#45;-with-libraries</option> in addition to this option. <filename>configure</filename> will check for the required header files and libraries to make sure that your GSSAPI installation is sufficient before proceeding. GSSAPI認証のサポートを構築します。 多くのシステムでは、GSSAPIシステム(通常Kerberosインストレーションの一部)はデフォルトの検索場所(例えば/usr/include/usr/lib)にインストールされていません。 そのため、--with-includes--with-librariesオプションをさらに追加して使わなければいけません。 configureは、処理を進める前にGSSAPIが正しくインストールされていることを確認するために、必要とされるヘッダファイルとライブラリを検査します。

--with-ldap

Build with <acronym>LDAP</acronym><indexterm><primary>LDAP</primary></indexterm> support for authentication and connection parameter lookup (see <phrase id="install-ldap-links"><xref linkend="libpq-ldap"/> and <xref linkend="auth-ldap"/></phrase> for more information). On Unix, this requires the <productname>OpenLDAP</productname> package to be installed. On Windows, the default <productname>WinLDAP</productname> library is used. <filename>configure</filename> will check for the required header files and libraries to make sure that your <productname>OpenLDAP</productname> installation is sufficient before proceeding. 認証および接続パラメータ検索用のLDAPサポートを有効にして構築します。 (詳細は34.18および21.10を参照してください。) Unixでは、OpenLDAPパッケージがインストールされていることが必要です。 WindowsではデフォルトのWinLDAPライブラリが使用されます。 configureは、処理を進める前にOpenLDAPのインストールが十分されているかどうかを確認するために、必要なヘッダファイルとライブラリを検査します。

--with-pam

Build with <acronym>PAM</acronym><indexterm><primary>PAM</primary></indexterm> (Pluggable Authentication Modules) support. PAM(プラガブル認証モジュール)のサポートを有効にして構築します。

--with-bsd-auth

Build with BSD Authentication support. (The BSD Authentication framework is currently only available on OpenBSD.) BSD認証のサポートを有効にして構築します。 (BSD認証フレームワークは今のところOpenBSDだけで利用可能です。)

--with-systemd

Build with support for <application>systemd</application><indexterm><primary>systemd</primary></indexterm> service notifications. This improves integration if the server is started under <application>systemd</application> but has no impact otherwise<phrase condition="standalone-ignore">; see <xref linkend="server-start"/> for more information</phrase>. <application>libsystemd</application> and the associated header files need to be installed to use this option. systemdサービス通知のサポートを有効にして構築します。 サーババイナリがsystemdの元で開始する場合には、これは統合を改善しますが、それ以外は影響はありません。詳細は19.3を参照してください。 このオプションを使えるようにするには、libsystemdと関連するヘッダファイルをインストールすることが必要です。

--with-bonjour

Build with support for Bonjour automatic service discovery. This requires Bonjour support in your operating system. Recommended on macOS. Bonjour自動サービス検出のサポートを有効にして構築します。 これには、オペレーティングシステムがBonjourをサポートしていることが必要です。 macOSでは推奨します。

--with-uuid=LIBRARY

Build the <xref linkend="uuid-ossp"/> module (which provides functions to generate UUIDs), using the specified UUID library.<indexterm><primary>UUID</primary></indexterm> <replaceable>LIBRARY</replaceable> must be one of: 指定されたUUIDライブラリを使用して(UUIDを生成する関数を提供する)uuid-osspモジュールをビルドします。 LIBRARYは以下のいずれかでなければなりません。

  • <option>bsd</option> to use the UUID functions found in FreeBSD and some other BSD-derived systems bsdはFreeBSD、その他のBSD派生システムにあるUUID関数を使います。

  • <option>e2fs</option> to use the UUID library created by the <literal>e2fsprogs</literal> project; this library is present in most Linux systems and in macOS, and can be obtained for other platforms as well e2fse2fsprogsプロジェクトで作られたUUIDライブラリを使います。 このライブラリはたいていのLinuxシステムとmacOSにあり、また、その他のプラットフォームでも入手可能です。

  • <option>ossp</option> to use the <ulink url="http://www.ossp.org/pkg/lib/uuid/">OSSP UUID library</ulink> osspOSSP UUIDライブラリを使用します。

--with-ossp-uuid

Obsolete equivalent of <literal>&#45;-with-uuid=ossp</literal>. --with-uuid=osspに相当する古いものです。

--with-libxml

Build with libxml2, enabling SQL/XML support. Libxml2 version 2.6.23 or later is required for this feature. libxml2を使用して構築し、SQL/XMLサポートを有効にします。 この機能のためにはlibxml2バージョン2.6.23以降が必要です。

To detect the required compiler and linker options, PostgreSQL will query <command>pkg-config</command>, if that is installed and knows about libxml2. Otherwise the program <command>xml2-config</command>, which is installed by libxml2, will be used if it is found. Use of <command>pkg-config</command> is preferred, because it can deal with multi-architecture installations better. pkg-configがインストールされていて、かつそれがlibxml2について知っているようであれば、必要なコンパイラオプション、リンカオプションを検出するために、PostgreSQLはpkg-configに問い合わせます。 そうでなければ、libxml2がインストールするプログラムxml2-configを見つけられれば使用します。 複数アーキテクチャのインストレーションをよりうまく扱えますので、pkg-configを使用する方が好ましいです。

To use a libxml2 installation that is in an unusual location, you can set <command>pkg-config</command>-related environment variables (see its documentation), or set the environment variable <envar>XML2_CONFIG</envar> to point to the <command>xml2-config</command> program belonging to the libxml2 installation, or set the variables <envar>XML2_CFLAGS</envar> and <envar>XML2_LIBS</envar>. (If <command>pkg-config</command> is installed, then to override its idea of where libxml2 is you must either set <envar>XML2_CONFIG</envar> or set both <envar>XML2_CFLAGS</envar> and <envar>XML2_LIBS</envar> to nonempty strings.) 通常以外の場所にインストールしたlibxml2インストレーションを使用するためには、pkg-config関連の環境変数を設定するか(そのドキュメントを参照してください)、環境変数XML2_CONFIGがそのインストレーション用のxml2-configプログラムを指し示すように設定するか、変数XML2_CFLAGSXML2_LIBSを設定します。 (pkg-configがインストールされていて、libxml2がどこにあるかについてのその認識を覆したいのであれば、XML2_CONFIGを、もしくはXML2_CFLAGSXML2_LIBSの両方を空でない文字列に設定しなければなりません。)

--with-libxslt

Build with libxslt, enabling the <xref linkend="xml2"/> module to perform XSL transformations of XML. <option>&#45;-with-libxml</option> must be specified as well. XMLのXSL変換を行うためにxml2モジュールを有効にしてlibxsltを構築します。 --with-libxmlも指定しなければなりません。

17.4.1.3. 機能の無効化

<title>Anti-Features</title>

The options described in this section allow disabling certain <productname>PostgreSQL</productname> features that are built by default, but which might need to be turned off if the required software or system features are not available. Using these options is not recommended unless really necessary. この節に書かれたオプションは、デフォルトでは構築されますが、必要なソフトウェアやシステムの機能が利用可能でない場合にオフにする必要があるPostgreSQLの特定の機能を無効にします。 本当に必要でない限りは、ここのプションの使用は勧められません。

--without-readline

Prevents use of the <application>Readline</application> library (and <application>libedit</application> as well). This option disables command-line editing and history in <application>psql</application>. Readlineライブラリ(およびlibedit)の使用を防止します。 このオプションはpsqlでのコマンドライン編集および履歴を無効にします。

--with-libedit-preferred

Favors the use of the BSD-licensed <application>libedit</application> library rather than GPL-licensed <application>Readline</application>. This option is significant only if you have both libraries installed; the default in that case is to use <application>Readline</application>. GPLライセンスのReadlineではなくBSDライセンスのlibeditライブラリを優先して使用します。 このオプションは両方のライブラリがインストールされている場合にのみ重要です。その場合デフォルトでReadlineが使用されます。

--without-zlib

Prevents use of the <application>Zlib</application> library. This disables support for compressed archives in <application>pg_dump</application> and <application>pg_restore</application>. Zlibライブラリの使用を抑制します。 これは、pg_dumppg_restoreにおける圧縮アーカイブのサポートを無効にします。

--disable-spinlocks

Allow the build to succeed even if <productname>PostgreSQL</productname> has no CPU spinlock support for the platform. The lack of spinlock support will result in very poor performance; therefore, this option should only be used if the build aborts and informs you that the platform lacks spinlock support. If this option is required to build <productname>PostgreSQL</productname> on your platform, please report the problem to the <productname>PostgreSQL</productname> developers. PostgreSQLがそのプラットフォーム用のCPUスピンロックをサポートしない場合でも、構築に成功するようにします。 スピンロックのサポートの欠落により、性能は悪化します。 したがって、このオプションは、構築が失敗し、その原因が使用するプラットフォームでスピンロックサポートが欠落している場合にのみ使用してください。 使用するプラットフォームにおけるPostgreSQLの構築にこのオプションが必要とされた場合は、PostgreSQL開発者にその問題を報告してください。

--disable-atomics

Disable use of CPU atomic operations. This option does nothing on platforms that lack such operations. On platforms that do have them, this will result in poor performance. This option is only useful for debugging or making performance comparisons. CPU不可分操作の使用を無効にします。 このオプションはそのような操作のないプラットフォームでは何もしません。 そのような操作のあるプラットフォームでは、これにより性能が低下するでしょう。 このオプションはデバッグや性能比較をする場合にのみ有用です。

--disable-thread-safety

Disable the thread-safety of client libraries. This prevents concurrent threads in <application>libpq</application> and <application>ECPG</application> programs from safely controlling their private connection handles. Use this only on platforms with deficient threading support. クライアントライブラリのスレッドセーフを無効にします。 これにより、libpqECPGプログラム内の同時実行スレッドは、安全にその固有の接続ハンドルを制御できなくなります。 スレッドのサポートに欠陥があるプラットフォームでのみ、これを使ってください。

17.4.1.4. 構築プロセスの詳細

<title>Build Process Details</title>
--with-includes=DIRECTORIES

<replaceable>DIRECTORIES</replaceable> 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 <application>Readline</application>) installed in a non-standard location, you have to use this option and probably also the corresponding <option>&#45;-with-libraries</option> option. DIRECTORIESには、コンパイラがヘッダファイルを検索するディレクトリのリストをコロンで区切って指定します。 (GNU Readlineなどの)オプションのパッケージが非標準的な場所にインストールされている場合、このオプションと、おそらく対応する--with-librariesオプションを使用する必要があります。

Example: <literal>&#45;-with-includes=/opt/gnu/include:/usr/sup/include</literal>. 例: --with-includes=/opt/gnu/include:/usr/sup/include

--with-libraries=DIRECTORIES

<replaceable>DIRECTORIES</replaceable> is a colon-separated list of directories to search for libraries. You will probably have to use this option (and the corresponding <option>&#45;-with-includes</option> option) if you have packages installed in non-standard locations. DIRECTORIESには、ライブラリを検索するディレクトリのリストをコロンで区切って指定します。 パッケージが非標準的な場所にインストールされている場合は、おそらくこのオプション(と対応する--with-includesオプション)を使用する必要があります。

Example: <literal>&#45;-with-libraries=/opt/gnu/lib:/usr/sup/lib</literal>. 例: --with-libraries=/opt/gnu/lib:/usr/sup/lib

--with-system-tzdata=DIRECTORY

<productname>PostgreSQL</productname> includes its own time zone database, which it requires for date and time operations. This time zone database is in fact compatible with the IANA time zone database provided by many operating systems such as FreeBSD, Linux, and Solaris, so it would be redundant to install it again. When this option is used, the system-supplied time zone database in <replaceable>DIRECTORY</replaceable> is used instead of the one included in the PostgreSQL source distribution. <replaceable>DIRECTORY</replaceable> must be specified as an absolute path. <filename>/usr/share/zoneinfo</filename> is a likely directory on some operating systems. Note that the installation routine will not detect mismatching or erroneous time zone data. If you use this option, you are advised to run the regression tests to verify that the time zone data you have pointed to works correctly with <productname>PostgreSQL</productname>. PostgreSQLは、日付時刻に関する操作で必要な、独自の時間帯データベースを持ちます。 実際のところ、この時間帯データベースはFreeBSD、Linux、Solarisなどの多くのオペレーティングシステムで提供されるIANA時間帯データベースと互換性があります。 このため、これを再びインストールすることは冗長です。 このオプションが使用されると、DIRECTORYにあるシステムが提供する時間帯データベースがPostgreSQLソース配布物に含まれるものの代わりに使用されます。 DIRECTORYは絶対パスで指定しなければなりません。 /usr/share/zoneinfoがオペレーティングシステムの一部でよく使われます。 インストール処理が時間帯データが一致しない、またはエラーがあることを検知しないことに注意してください。 このオプションを使用する場合、指定した時間帯データがPostgreSQLで正しく動作するかどうかを検証するためにリグレッションテストを実行することが推奨されています。

This option is mainly aimed at binary package distributors who know their target operating system well. The main advantage of using this option is that the PostgreSQL package won't need to be upgraded whenever any of the many local daylight-saving time rules change. Another advantage is that PostgreSQL can be cross-compiled more straightforwardly if the time zone database files do not need to be built during the installation. このオプションは、対象オペレーティングシステムを熟知しているパッケージ配布者を主な対象としたもの。 このオプションを使用する大きな利点は、多くの局所的な夏時間規則の変更があってもPostgreSQLパッケージを更新する必要がないことです。 他の利点として、時間帯データベースファイルをインストール時に構築する必要がありませんので、PostgreSQLのクロスコンパイルをより簡単に行うことができます。

--with-extra-version=STRING

Append <replaceable>STRING</replaceable> to the PostgreSQL version number. You can use this, for example, to mark binaries built from unreleased Git snapshots or containing custom patches with an extra version string, such as a <command>git describe</command> identifier or a distribution package release number. PostgreSQLバージョン番号にSTRINGを追加します。 これは、例えば、リリースされていないGitスナップショットからビルドしたバイナリや、git describe識別子やディストリビューションパッケージリリース番号のような追加のバージョン文字列のあるカスタムパッチを含むバイナリに印をつけるために使えます。

--disable-rpath

Do not mark <productname>PostgreSQL</productname>'s executables to indicate that they should search for shared libraries in the installation's library directory (see <option>&#45;-libdir</option>). On most platforms, this marking uses an absolute path to the library directory, so that it will be unhelpful if you relocate the installation later. However, you will then need to provide some other way for the executables to find the shared libraries. Typically this requires configuring the operating system's dynamic linker to search the library directory; see <xref linkend="install-post-shlibs"/> for more detail. PostgreSQLの実行ファイルがインストレーションのライブラリディレクトリ(--libdirを参照してください)にある共有ライブラリを探すよう指示する印を付けません。 ほとんどのプラットフォームでは、この印付けはライブラリディレクトリへの絶対パスを利用しますので、後でインストレーションを再配置したときには役に立たないでしょう。 ですので、実行ファイルが共有ライブラリを見つける他の方法を提供する必要があるでしょう。 通常は、オペレーティングシステムの動的リンカがライブラリディレクトリを探すよう設定することが必要です。詳細は17.5.1を参照してください。

17.4.1.5. その他

<title>Miscellaneous</title>

It's fairly common, particularly for test builds, to adjust the default port number with <option>&#45;-with-pgport</option>. The other options in this section are recommended only for advanced users. デフォルトのポート番号を--with-pgportで調整することは、特にテスト構築のためには、かなり良くあることです。 この節の他のオプションは上級ユーザにのみ勧められます。

--with-pgport=NUMBER

Set <replaceable>NUMBER</replaceable> 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. Usually the only good reason to select a non-default value is if you intend to run multiple <productname>PostgreSQL</productname> servers on the same machine. サーバとクライアントのデフォルトのポート番号をNUMBERに設定します。 デフォルトは5432です。 このポートは後でいつでも変更することができますが、ここで指定した場合、サーバとクライアントはコンパイル時に同じデフォルト値を持つようになります。 これは非常に便利です。 通常、デフォルト以外の値を選択すべき唯一の理由は、同じマシンで複数のPostgreSQLを稼働させることです。

--with-krb-srvnam=NAME

The default name of the Kerberos service principal used by GSSAPI. <literal>postgres</literal> is the default. There's usually no reason to change this unless you are building for a Windows environment, in which case it must be set to upper case <literal>POSTGRES</literal>. GSSAPIで使用されるKerberosのサービスプリンシパルのデフォルトの名前です。 デフォルトではpostgresです。 これを変える理由はWindows環境のために構築しているのでない限り、特にありません。 Windows環境のために構築している場合は大文字のPOSTGRESに設定する必要があります。

--with-segsize=SEGSIZE

Set the <firstterm>segment size</firstterm>, in gigabytes. Large tables are divided into multiple operating-system files, each of size equal to the segment size. This avoids problems with file size limits that exist on many platforms. The default segment size, 1 gigabyte, is safe on all supported platforms. If your operating system has <quote>largefile</quote> support (which most do, nowadays), you can use a larger segment size. This can be helpful to reduce the number of file descriptors consumed when working with very large tables. But be careful not to select a value larger than is supported by your platform and the file systems you intend to use. Other tools you might wish to use, such as <application>tar</application>, could also set limits on the usable file size. It is recommended, though not absolutely required, that this value be a power of 2. Note that changing this value breaks on-disk database compatibility, meaning you cannot use <command>pg_upgrade</command> to upgrade to a build with a different segment size. セグメントサイズをギガバイト単位で指定します。 大規模なテーブルはこのセグメントサイズと同じサイズの複数のオペレーティングシステムのファイルに分割されます。 これにより多くのプラットフォームで存在するファイルサイズ上限に関する問題を防ぎます。 デフォルトのセグメントサイズは1ギガバイトで、サポートされるすべてのプラットフォームで安全です。 使用するオペレーティングシステムがラージファイルをサポートしていれば(最近はほとんどサポートしています)、より大きなセグメントサイズを使用することができます。 非常に大規模なテーブルで作業する時のファイル記述子の消費数を減らすために、これが役に立つでしょう。 しかし、プラットフォーム、または使用予定のファイルシステムでサポートされる値以上に大きな値を指定しないように注意してください。 tarなどの、使用したいその他のツールにも使用できるファイルサイズに制限があることがあります。 絶対に必要ではありませんが、この値を2のべき乗にすることを勧めます。 この値を変更するとディスク上でのデータベースの互換性を壊すことに注意してください。すなわち、pg_upgradeを使ってセグメントサイズの異なるビルドにはアップグレードできません。

--with-blocksize=BLOCKSIZE

Set the <firstterm>block size</firstterm>, in kilobytes. This is the unit of storage and I/O within tables. The default, 8 kilobytes, is suitable for most situations; but other values may be useful in special cases. The value must be a power of 2 between 1 and 32 (kilobytes). Note that changing this value breaks on-disk database compatibility, meaning you cannot use <command>pg_upgrade</command> to upgrade to a build with a different block size. キロバイト単位でブロック容量を設定します。 これはテーブル内でのストレージとI/Oの単位です。 8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は他の値が役立ちます。 値は1から32(キロバイト)の範囲の2のべき乗でなければなりません。 この値を変更するとディスク上でのデータベースの互換性を壊すことに注意してください。すなわち、pg_upgradeを使ってブロック容量の異なるビルドにはアップグレードできません。

--with-wal-blocksize=BLOCKSIZE

Set the <firstterm>WAL block size</firstterm>, in kilobytes. This is the unit of storage and I/O within the WAL log. The default, 8 kilobytes, is suitable for most situations; but other values may be useful in special cases. The value must be a power of 2 between 1 and 64 (kilobytes). Note that changing this value breaks on-disk database compatibility, meaning you cannot use <command>pg_upgrade</command> to upgrade to a build with a different WAL block size. キロバイト単位でWALブロック容量を設定します。 これはWALログ内でのストレージとI/Oの単位です。 8キロバイトのデフォルトはほとんどの場合適切ですが、特別な場合は大きめの値が役立ちます。 値は1から64(キロバイト)の範囲の2のべき乗でなければなりません。 この値を変更するとディスク上でのデータベースの互換性を壊すことに注意してください。すなわち、pg_upgradeを使ってWALブロック容量の異なるビルドにはアップグレードできません。

17.4.1.6. 開発者向けオプション

<title>Developer Options</title>

Most of the options in this section are only of interest for developing or debugging <productname>PostgreSQL</productname>. They are not recommended for production builds, except for <option>&#45;-enable-debug</option>, which can be useful to enable detailed bug reports in the unlucky event that you encounter a bug. On platforms supporting DTrace, <option>&#45;-enable-dtrace</option> may also be reasonable to use in production. この節のオプションのほとんどは、PostgreSQLを開発したりデバッグしたりするために重要なものです。 --enable-debugを除いて、実運用での構築には勧められません。--enable-debugはバグに出くわすという不幸な出来事の時に詳細なバグレポートが得られるので有用かもしれません。 DTraceをサポートするプラットフォームでは、--enable-dtraceを実運用で使うことも適当かもしれません。

When building an installation that will be used to develop code inside the server, it is recommended to use at least the options <option>&#45;-enable-debug</option> and <option>&#45;-enable-cassert</option>. サーバ内でコードの開発に使われるインストレーションを構築する場合には、少なくともオプション--enable-debug--enable-cassertを使うことをお勧めします。

--enable-debug

Compiles all programs and libraries with debugging symbols. This means that you can run the programs in a debugger to analyze problems. This enlarges the size of the installed executables considerably, and on non-GCC compilers it usually also disables compiler optimization, causing slowdowns. However, having the symbols available is extremely helpful for dealing with any problems that might arise. Currently, this option is recommended for production installations only if you use GCC. But you should always have it on if you are doing development work or running a beta version. すべてのプログラムとライブラリをデバッグシンボル付きでコンパイルします。 これは、問題を解析するためにデバッガ内でプログラムを実行できることを意味します。 これはインストールする実行形式ファイルのサイズをかなり大きくし、また、GCC以外のコンパイラでは、通常はコンパイラによる最適化が行われなくなりますので、低速になります。 しかし、デバッグシンボルが利用できるということは、発生した問題に対応する時に非常に便利です。 現在のところ、GCC を使用している場合にのみ、稼働用のインストレーションにこのオプションを使用することを推奨します。 しかし、開発作業時やベータ版を実行する時は、常にこれを有効にすべきです。

--enable-cassert

Enables <firstterm>assertion</firstterm> checks in the server, which test for many <quote>cannot happen</quote> conditions. This is invaluable for code development purposes, but the tests can slow down the server significantly. Also, having the tests turned on won't necessarily enhance the stability of your server! The assertion checks are not categorized for severity, and so what might be a relatively harmless bug will still lead to server restarts if it triggers an assertion failure. This option is not recommended for production use, but you should have it on for development work or when running a beta version. サーバにおける、多くのあり得ない状態をテストするアサーションチェックを有効にします。 これは、プログラムの開発のためには測り知れない価値がありますが、このテストによりサーバはかなり低速になります。 また、このテストを有効にしても、サーバの安定性が向上するとは限りません! アサーションチェックは、重要度によって分類されていませんので、比較的害がないようなバグでも、アサーション失敗をトリガとした、サーバの再起動が行われてしまいます。 稼働用にこのオプションを使用することは推奨されませんが、開発作業時やベータ版を実行する場合は、これを有効にすべきです。

--enable-tap-tests

Enable tests using the Perl TAP tools. This requires a Perl installation and the Perl module <literal>IPC::Run</literal>. <phrase condition="standalone-ignore">See <xref linkend="regress-tap"/> for more information.</phrase> Perl TAPツールを使ったテストを有効にします。 これにはPerlのインストールとPerlモジュールIPC::Runが必要です。 詳細は33.4を参照してください。

--enable-depend

Enables automatic dependency tracking. With this option, the makefiles are set up so that all affected object files will be rebuilt when any header file is changed. This is useful if you are doing development work, but is just wasted overhead if you intend only to compile once and install. At present, this option only works with GCC. 自動依存関係追跡を有効にします。 このオプションを使用すると、ヘッダファイルが変更された場合に、影響を受ける全てのオブジェクトファイルが再構築されるように、makefile が設定されます。 これは開発作業時には有用ですが、単に一度コンパイルしインストールするだけであれば、これは無駄なオーバーヘッドです。 現在のところ、GCC でのみ、このオプションは動作します。

--enable-coverage

If using GCC, all programs and libraries are compiled with code coverage testing instrumentation. When run, they generate files in the build directory with code coverage metrics. <phrase condition="standalone-ignore">See <xref linkend="regress-coverage"/> for more information.</phrase> This option is for use only with GCC and when doing development work. GCCを使用している場合、すべてのプログラムとライブラリはコードカバレッジ試験機構付きでコンパイルされます。 実行すると、これらは構築用ディレクトリ内にコードカバレッジメトリックを持ったファイルを生成します。 詳細は33.5を参照してください。 このオプションはGCC専用であり、また、開発作業中に使用するためのものです。

--enable-profiling

If using GCC, all programs and libraries are compiled so they can be profiled. On backend exit, a subdirectory will be created that contains the <filename>gmon.out</filename> file containing profile data. This option is for use only with GCC and when doing development work. GCCを使用する場合、すべてのプログラムとライブラリがプロファイリング可能状態でコンパイルされます。 バックエンドの終了時、プロファイリングに使用するgmon.outファイルを含むサブディレクトリが作成されます。 このオプションはGCCを使用する場合のみ使用でき、開発作業を行う時に使用します。

--enable-dtrace

Compiles <productname>PostgreSQL</productname> with support for the dynamic tracing tool DTrace. <phrase condition="standalone-ignore">See <xref linkend="dynamic-trace"/> for more information.</phrase> 動的追跡ツールDTraceのサポートを有効にしてPostgreSQLをコンパイルします。 より詳細な情報は28.5を参照してください。

To point to the <command>dtrace</command> program, the environment variable <envar>DTRACE</envar> can be set. This will often be necessary because <command>dtrace</command> is typically installed under <filename>/usr/sbin</filename>, which might not be in your <envar>PATH</envar>. dtraceプログラムを指し示すためにDTRACE環境変数を設定することができます。 dtraceは通常、PATH内に存在しない可能性がある/usr/sbin以下にインストールされていますので、この設定はよく必要になります。

Extra command-line options for the <command>dtrace</command> program can be specified in the environment variable <envar>DTRACEFLAGS</envar>. On Solaris, to include DTrace support in a 64-bit binary, you must specify <literal>DTRACEFLAGS="-64"</literal>. For example, using the GCC compiler: さらにdtraceプログラム用のコマンドラインオプションをDTRACEFLAGS環境変数で指定できます。 Solarisで64ビットバイナリでDTraceをサポートするには、DTRACEFLAGS="-64"を指定してください。 例えばGCCコンパイラを使用する場合は以下のようにします。

./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...

Using Sun's compiler: Sunのコンパイラを使用する場合は以下のようにします。

./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...

17.4.2. configure環境変数

<title><filename>configure</filename> Environment Variables</title>

In addition to the ordinary command-line options described above, <filename>configure</filename> responds to a number of environment variables. You can specify environment variables on the <filename>configure</filename> command line, for example: 上記の通常のコマンドラインオプションに加えて、configureは数多くの環境変数に対応します。 次のようにして、configureコマンドラインに環境変数を指定できます。

./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'

In this usage an environment variable is little different from a command-line option. You can also set such variables beforehand: この使い方では、環境変数はコマンドラインオプションとは少し異なります。 あらかじめそのような変数を設定しておくこともできます。

export CC=/opt/bin/gcc
export CFLAGS='-O2 -pipe'
./configure

This usage can be convenient because many programs' configuration scripts respond to these variables in similar ways. 多くのプログラムの設定スクリプトは似たようにこの変数に対応しますので、この使い方は便利でしょう。

The most commonly used of these environment variables are <envar>CC</envar> and <envar>CFLAGS</envar>. If you prefer a C compiler different from the one <filename>configure</filename> picks, you can set the variable <envar>CC</envar> to the program of your choice. By default, <filename>configure</filename> will pick <filename>gcc</filename> if available, else the platform's default (usually <filename>cc</filename>). Similarly, you can override the default compiler flags if needed with the <envar>CFLAGS</envar> variable. これらの環境変数の中で最も一般的に使用されているのは、CCCFLAGSです。 configureが選ぶものと違うCコンパイラを使いたいという場合には、CC 環境変数をその使用したいプログラムに設定することができます。 デフォルトでは、configureは利用できるのであればgccを、利用できなければプラットフォームのデフォルト(通常cc)を選択します。 同様に、デフォルトのコンパイラフラグは必要に応じてCFLAGS変数で上書きすることもできます。

Here is a list of the significant variables that can be set in this manner: 以下は、この方式で設定可能な重要な環境変数の一覧です。

BISON

Bison program Bisonプログラム。

CC

C compiler Cコンパイラ。

CFLAGS

options to pass to the C compiler Cコンパイラに渡すオプション。

CLANG

path to <command>clang</command> program used to process source code for inlining when compiling with <literal>&#45;-with-llvm</literal> --with-llvmでコンパイルされた場合、ソースコードのインライン展開を処理するために使われるclangプログラムへのパス。

CPP

C preprocessor Cプリプロセッサ。

CPPFLAGS

options to pass to the C preprocessor Cプリプロセッサに渡すオプション。

CXX

C++ compiler C++コンパイラ。

CXXFLAGS

options to pass to the C++ compiler C++コンパイラに渡すオプション。

DTRACE

location of the <command>dtrace</command> program dtraceプログラムの場所。

DTRACEFLAGS

options to pass to the <command>dtrace</command> program dtraceプログラムに渡すオプション。

FLEX

Flex program Flexプログラム。

LDFLAGS

options to use when linking either executables or shared libraries 実行ファイルや共有ライブラリにリンクする場合に使用するオプション。

LDFLAGS_EX

additional options for linking executables only 実行ファイルのリンク時のみに追加されるオプション。

LDFLAGS_SL

additional options for linking shared libraries only 共有ライブラリのリンク時のみに追加されるオプション。

LLVM_CONFIG

<command>llvm-config</command> program used to locate the <productname>LLVM</productname> installation LLVMインストレーションの場所を特定するために使用するllvm-configプログラム。

MSGFMT

<command>msgfmt</command> program for native language support 多言語サポート(NLS)用のmsgfmtプログラム。

PERL

Perl interpreter program. This will be used to determine the dependencies for building PL/Perl. The default is <command>perl</command>. Perlインタプリタプログラム。 これは、PL/Perl構築に関する依存性を決定するために使用されます。 デフォルトはperlです。

PYTHON

Python interpreter program. This will be used to determine the dependencies for building PL/Python. If this is not set, the following are probed in this order: <literal>python3 python</literal>. Pythonインタプリタプログラム。 これは、PL/Python構築に関する依存性を決定するために使用されます。 設定されていなければ、python3 pythonの順で調べられます。

TCLSH

Tcl interpreter program. This will be used to determine the dependencies for building PL/Tcl. If this is not set, the following are probed in this order: <literal>tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85 tclsh8.4 tclsh84</literal>. Tclインタプリタプログラム。 これは、PL/Tcl構築に関する依存性を決定するために使用され、Tclスクリプト内を置き換えます。 設定されていなければ、以下の順で調べられます。tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85 tclsh8.4 tclsh84

XML2_CONFIG

<command>xml2-config</command> program used to locate the libxml2 installation libxml2インストレーションの場所を特定するために使用するxml2-configプログラムです。

Sometimes it is useful to add compiler flags after-the-fact to the set that were chosen by <filename>configure</filename>. An important example is that <application>gcc</application>'s <option>-Werror</option> option cannot be included in the <envar>CFLAGS</envar> passed to <filename>configure</filename>, because it will break many of <filename>configure</filename>'s built-in tests. To add such flags, include them in the <envar>COPT</envar> environment variable while running <filename>make</filename>. The contents of <envar>COPT</envar> are added to both the <envar>CFLAGS</envar> and <envar>LDFLAGS</envar> options set up by <filename>configure</filename>. For example, you could do configureが選んだコンパイラフラグに対して、事後にフラグを追加することが有用な場合があります。 重要な例は、configureに渡すCFLAGSgcc-Werrorオプションを含められないことです。なぜなら、そうするとconfigureの組み込みテストの多くが失敗するからです。 そのようなフラグを追加するには、makeを実行する時にCOPT環境変数に含めてください。 configureで設定されたCFLAGSオプションとLDFLAGSオプションの両方に、COPTの内容が追加されます。 例えば、以下のようにします。

make COPT='-Werror'

or または

export COPT='-Werror'
make

注記

If using GCC, it is best to build with an optimization level of at least <option>-O1</option>, because using no optimization (<option>-O0</option>) disables some important compiler warnings (such as the use of uninitialized variables). However, non-zero optimization levels can complicate debugging because stepping through compiled code will usually not match up one-to-one with source code lines. If you get confused while trying to debug optimized code, recompile the specific files of interest with <option>-O0</option>. An easy way to do this is by passing an option to <application>make</application>: <command>make PROFILE=-O0 file.o</command>. GCCを使う場合、少なくとも-O1レベルの最適化で構築することがベストです。なぜなら、何の最適化もしない(-O0) と、重要なコンパイル警告(初期化されていない変数の使用など)が無効になるからです。 しかし、最適化を行うことでソースコードとコンパイルされたコードのステップは1対1とはならなくなるため、デバッグは複雑になるかもしれません。 最適化されたコードのデバッグに悩まされてしまう場合は、関心のある特定のファイルに対して-O0で再コンパイルしてください。 これを実行するための簡単な方法は、make PROFILE=-O0 file.oのように、make経由でオプションを渡すことです。

The <envar>COPT</envar> and <envar>PROFILE</envar> environment variables are actually handled identically by the <productname>PostgreSQL</productname> makefiles. Which to use is a matter of preference, but a common habit among developers is to use <envar>PROFILE</envar> for one-time flag adjustments, while <envar>COPT</envar> might be kept set all the time. COPTPROFILEの環境変数は、PostgreSQLのmakefileでは実際には全く同一に扱われます。 どちらを使うかは好みの問題ですが、開発者の一般的な習慣では、一時的にフラグを調整するにはPROFILEを使い、永続的に保持するものにはCOPTを使います。