codecamp

PostgreSQL 安装过程

16.4.1. configure 选项
16.4.2. configure 环境变量
  1. 配置

    安装过程的第一步就是为你的系统配置源代码树并选择你喜欢的选项。这个工作是通过运行configure脚本实现的,对于默认安装,你只需要简单地输入:

    ./configure
    

    该脚本将运行一些测试来决定一些系统相关的变量, 并检测你的操作系统的特殊设置,并且最后将在编译树中创建一些文件以记录它找到了什么。

    如果你想保持编译目录的独立,你也可以在一个源码树之外的目录中运行configure ,然后在那里构建。这个过程也被称为一个 VPATH编译。做法如下:

    mkdir build_dir
    cd build_dir
    /path/to/source/tree/configure [options go here]
    make
    

    默认设置将编译服务器和辅助程序,还有只需要 C 编译器的所有客户端程序和接口。默认时所有文件都将安装到/usr/local/pgsql

    您可以通过向configure提供一个或多个命令行选项来自定义构建和安装过程。 通常,您会自定义安装位置或构建的一组可选功能。configure有大量的选项, 在本文中第 16.4.1 节中有描述。

    此外,configure响应某些环境变量,如在本文中第 16.4.2 节中所述。 这些提供了自定义配置的其他方法。

  2. Build

    要开始构建,请键入:

    make
    make all
    

    (记得使用GNU make。) 构建将需要几分钟时间,具体取决于您的硬件。 显示的最后一行应该是:

    All of PostgreSQL successfully made. Ready to install.
    

    如果您想构建可以构建的所有内容,包括文档(HTML 和手册页)和附加模块(contrib),请改为键入:

    make world
    

    显示的最后一行应该是:

    PostgreSQL, contrib, and documentation successfully made. Ready to install.
    

    如果要从另一个 makefile 调用构建而不是手动调用,则必须取消设置MAKELEVEL或将其设置为零,例如:

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

    不这样做可能会导致奇怪的错误消息,通常是关于缺少头文件。

  3. 回归测试

    如果您想在安装之前测试新构建的服务器,您可以在此时运行回归测试。 回归测试是一个测试套件,用于验证PostgreSQL 是否以开发人员期望的方式在您的机器上运行。输入:

    make check
    

    (这不会以 root 身份运行;以非特权用户身份进行。)有关解释测试结果的详细信息, 请参阅第 32 章。您可以在以后的任何时间通过发出相同的命令重复此测试。

  4. 安装文件

    注意

    如果您要升级现有系统,请务必阅读第 18.6 节,其中包含有关升级集群的说明。

    要安装PostgreSQL,请输入:

    make install
    

    这会将文件安装到本文中步骤 1 配置 中指定的目录中。 确保您具有写入该区域的适当权限。通常,您需要以 root 身份执行此步骤。 或者,您可以提前创建目标目录并安排授予适当的权限。

    要安装文档(HTML 和手册页),请输入:

    make install-docs
    

    如果您构建了上面的文档,请输入:

    make install-world
    

    这也会安装文档。

    您可以使用make install-strip而不是 make install来剥离安装的可执行文件和库。这将节省一些空间。 如果您使用调试支持构建,剥离将有效地移除调试支持,因此只有在不再需要调试时才应该这样做。 install-strip试图做一个合理的工作来节省空间, 但它不知道如何从可执行文件中去除每个不需要的字节,所以如果你想节省所有的磁盘空间, 你可能可以,你将不得不做手工工作。

    标准安装提供客户端应用程序开发以及服务器端程序开发所需的所有头文件,例如用 C 编写的自定义函数或数据类型。(在PostgreSQL 8.0 之前,单独的make install-all-headers命令,但此步骤已合并到标准安装中。)

    仅客户端安装:.  如果只想安装客户端应用程序和接口库,则可以使用以下命令:

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

    src/bin有一些仅供服务器使用的二进制文件,但它们很小。

卸载:.  要撤消安装,请使用命令make uninstall。但是,这不会删除任何创建的目录。

清理:.  安装后,您可以通过使用命令make clean从源树中删除构建的文件来释放磁盘空间。 这将保留configure程序生成的文件,以便您稍后可以使用make重建所有内容。 要将代码树重置为分发时的状态,请使用make distclean。如果要在同一源代码树中为多个平台构建, 则必须执行此操作并为每个平台重新配置。(或者,为每个平台使用单独的构建树,以便源树保持不变。)

如果您执行构建然后发现您的configure选项错误,或者如果您更改了configure调查的任何内容(例如,软件升级),那么在重新配置和重建之前执行make distclean是个好主意。 没有这个,您对配置选择的更改可能不会传播到他们需要的任何地方。

16.4.1. configure 选项

configure的命令行选项解释如下。 这个列表并不详尽(使用./configure --help 来获得一个)。此处未涵盖的选项适用于交叉编译等高级用例,并记录在标准Autoconf文档中。

16.4.1.1. 安装位置

这些选项控制make install将放置文件的位置。 --prefix选项在大多数情况下就足够了。 如果您有特殊需要,可以使用本节中描述的其他选项自定义安装子目录。 但是请注意,更改不同子目录的相对位置可能会使安装不可重定位,这意味着您将无法在安装后移动它。 (mandoc 位置不受此限制的影响。) 对于可重定位安装,您可能需要使用--disable-rpath选项稍后描述。

--prefix=PREFIX

把所有文件装在目录PREFIX中而不是/usr/local/pgsql中。 实际的文件会安装到数个子目录中;没有一个文件会直接安装到PREFIX目录里。

--exec-prefix=EXEC-PREFIX

你可以把体系相关的文件安装到一个不同的前缀下(EXEC-PREFIX),而不是PREFIX中设置的地方。 这样做可以比较方便地在不同主机之间共享体系相关的文件。 如果你省略这些,那么EXEC-PREFIX就会被设置为等于 PREFIX并且体系相关和体系无关的文件都会安装到同一棵目录树下,这也可能是你想要的。

--bindir=DIRECTORY

为可执行程序指定目录。默认是EXEC-PREFIX /bin, 通常也就是/usr/local/pgsql/bin

--sysconfdir=DIRECTORY

用于各种各样配置文件的目录,默认为PREFIX /etc

--libdir=DIRECTORY

设置安装库和动态装载模块的目录。默认是EXEC-PREFIX /lib

--includedir=DIRECTORY

C 和 C++ 头文件的目录。默认是PREFIX /include

--datarootdir=DIRECTORY

设置多种只读数据文件的根目录。这只为后面的某些选项设置默认值。默认值为PREFIX /share

--datadir=DIRECTORY

设置被安装的程序使用的只读数据文件的目录。默认值为DATAROOTDIR 。注意这不会对你的数据库文件被放置的位置产生任何影响。

--localedir=DIRECTORY

设置安装区域数据的目录,特别是消息翻译目录文件。默认值为DATAROOTDIR /locale

--mandir=DIRECTORY

PostgreSQL自带的手册页将安装到这个目录,它们被安装在相应的manx 子目录里。 默认是DATAROOTDIR /man

--docdir=DIRECTORY

设置安装文档文件的根目录,man页不包含在内。这只为后续选项设置默认值。这个选项的默认值为DATAROOTDIR /doc/postgresql

--htmldir=DIRECTORY

PostgreSQL的HTML格式的文档将被安装在这个目录中。默认值为DATAROOTDIR

注意

为了让PostgreSQL能够安装在一些共享的安装位置(例如/usr/local/include), 同时又不至于和系统其它部分产生名字空间干扰,我们特别做了一些处理。 首先,安装脚本会自动给datadirsysconfdirdocdir后面附加上 /postgresql字符串, 除非展开的完整路径名已经包含字符串postgres或者pgsql。 例如,如果你选择/usr/local作为前缀, 那么文档将安装在/usr/local/doc/postgresql,但如果前缀是/opt/postgres, 那么它将被放到/opt/postgres/doc。客户接口的公共 C 头文件安装到了includedir,并且是名字空间无关的。内部的头文件和服务器头文件都安装在 includedir下的私有目录中。参考每种接口的文档获取关于如何访问头文件的信息。最后,如果合适,那么也会在libdir下创建一个私有的子目录用于动态可装载的模块。

16.4.1.2. PostgreSQL 特性

本节中描述的选项支持构建默认情况下未构建的各种PostgreSQL功能。 其中大部分是非默认的,只是因为它们需要额外的软件,如第 16.2 节中所述。

--enable-nls[=LANGUAGES]

打开本地语言支持(NLS),也就是以非英文显示程序消息的能力。LANGUAGES是一个空格分隔的语言代码列表, 表示你想支持的语言。例如--enable-nls='de fr' (你提供的列表和实际支持的列表之间的交集将会自动计算出来)。如果你没有声明一个列表,那么就会安装所有可用的翻译。

要使用这个选项,你需要一个Gettext API 的实现。

--with-perl

制作PL/Perl服务器端编程语言。

--with-python

制作PL/Python服务器端编程语言。

--with-tcl

制作PL/Tcl服务器编程语言。

--with-tclconfig=DIRECTORY

Tcl 安装文件tclConfig.sh,其中里面包含编译与 Tcl 接口的模块的配置信息。该文件通常可以自动地在一个众所周知的位置找到,但是如果你需要一个不同版本的 Tcl, 您可以指定在其中查找tclConfig.sh的目录。

--with-icu

构建时支持ICU 库,从而能够使用 ICU 整理功能(请参阅 第 23.2 节)。 这需要安装ICU4C包。 ICU4C的最低要求版本目前是 4.2。

默认情况下,pkg-config 将用于查找所需的编译选项。ICU4C4.6 及更高版本支持此功能。 对于旧版本,或者如果pkg-config 不可用,可以将变量ICU_CFLAGSICU_LIBS指定为configure,就像在这个例子中:

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

(如果ICU4C在编译器的默认搜索路径中, 那么您仍然需要指定非空字符串以避免使用pkg-config, 例如,ICU_CFLAGS=' '。)

--with-llvm

支持基于LLVMJIT编译 (请参阅第 31 章。 这需要安装LLVM库。 当前LLVM的最低要求版本是3.9。

llvm-config 可用于查找所需的编译选项。llvm-config会在PATH 上搜索所有受支持版本的llvm-config-$major-$minor。 如果这不会产生所需的程序,请使用LLVM_CONFIG指定正确的 llvm-config的路径。例如:

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

LLVM支持需要兼容的clang编译器 (必要时使用CLANG环境变量指定)和有效的C++编译器 (必要时使用使用CXX环境变量指定)。

--with-openssl

编译SSL(加密)连接支持。这个选项需要安装OpenSSL包。configure将会检查所需的头文件和库以确保你的 OpenSSL安装足以让配置继续下去。

--with-gssapi

构建支持 GSSAPI 身份验证。在许多系统上,GSSAPI 系统(通常是 Kerberos 安装的一部分) 并未安装在默认搜索的位置(例如,/usr/include/usr/lib),因此除此选项外,您还必须使用选项 --with-includes--with-librariesconfigure将检查所需的头文件和库,以确保您的 GSSAPI 安装足够,然后再继续。

--with-ldap

为认证和连接参数查找编译LDAP 支持 (详见第 33.17 节第 20.10 节)。在 Unix 上,这需要安装OpenLDAP包。在 Windows 上将使用默认的WinLDAP库。configure将会检查所需的头文件和库以确保你的 OpenLDAP安装足以让配置继续下去。

--with-pam

使用PAM (可插拔身份验证模块)支持构建。

--with-bsd-auth

使用 BSD 身份验证支持构建。(BSD 身份验证框架目前仅在 OpenBSD 上可用。)

--with-systemd

编译对systemd 服务通知的支持。如果服务器是在systemd 机制下被启动,这可以提高集成度,否则不会有影响 否则,; 参考 第 18.3 节 查看更多信息 。要使用这个选项,必须安装libsystemd 以及相关的头文件。

--with-bonjour

构建支持 Bonjour 自动服务发现。这需要您的操作系统支持 Bonjour。推荐在 macOS 上使用。

--with-uuid=LIBRARY

使用指定的 UUID 库编译uuid-ossp模块(提供生成 UUID 的函数)。 LIBRARY必须是下列之一:

  • bsd,用来使用 FreeBSD、NetBSD 和一些其他 BSD 衍生系统 中的 UUID 函数

  • e2fs,用来使用e2fsprogs项目创建的 UUID 库, 这个库出现在大部分的 Linux 系统和 macOS 中,并且也能找到用于其他平台的 版本

  • ossp,用来使用OSSP UUID library

--with-ossp-uuid

--with-uuid=ossp的已废弃的等效选项。

--with-libxml

使用 libxml2 构建,启用 SQL/XML 支持。 此功能需要 Libxml2 版本 2.6.23 或更高版本。

为了检测所需的编译器和链接器选项,PostgreSQL 将查询pkg-config,如果它已安装并且知道 libxml2。 否则,libxml2 安装的程序xml2-config将在找到时使用。 首选使用pkg-config,因为它可以更好地处理多架构安装。

要使用位于不寻常位置的 libxml2 安装,您可以设置与pkg-config相关的环境变量(请参阅其文档),或将环境变量XML2_CONFIG设置为指向 到属于 libxml2 安装的xml2-config程序,或设置变量XML2_CFLAGSXML2_LIBS。 (如果安装了pkg-config,那么要覆盖它的 libxml2 位置的想法,您必须设置XML2_CONFIG或同时设置XML2_CFLAGSXML2_LIBS到非空字符串。)

--with-libxslt

使用 libxslt 构建,使xml2模块能够执行 XML 的 XSL 转换。 --with-libxml也必须指定。

16.4.1.3. Anti-Features

本节中描述的选项允许禁用默认构建的某些PostgreSQL功能, 但如果所需的软件或系统功能不可用,则可能需要关闭这些功能。除非确实有必要,否则不建议使用这些选项。

--without-readline

防止使用Readline库(以及libedit)。 此选项禁用psql中的命令行编辑和历史记录。

--with-libedit-preferred

赞成使用 BSD 许可的libedit库而不是 GPL 许可的Readline。 仅当您安装了两个库时,此选项才有意义; 这种情况下的默认设置是使用Readline

--without-zlib

防止使用Zlib库。这将禁用对pg_dumppg_restore中压缩档案的支持。

--disable-spinlocks

即便PostgreSQL对于该平台没有 CPU 自旋锁支持,也允许编译成功。自旋锁支持的缺乏会导致非常差的性能,因此这个选项只有当编译终端或者通知你该平台缺乏自旋锁支持时才应被使用。如果在你的平台上要求使用该选项来编译PostgreSQL,请将此问题报告给PostgreSQL的开发者。

--disable-atomics

禁用 CPU 原子操作。 此选项在缺少此类操作的平台上不起作用。 在具有它们的平台上,这将导致性能不佳。 此选项仅用于调试或进行性能比较。

--disable-thread-safety

禁用客户端库的线程安全性。这会阻止libpqECPG程序中的并发线程安全地控制它们私有的连接句柄。仅在线程支持不足的平台上使用它。

16.4.1.4. 构建过程详细信息

--with-includes=DIRECTORIES

DIRECTORIES是一个以冒号分隔的目录列表,这些目录将被添加到编译器搜索头文件的列表中。 如果您在非标准位置安装了可选包(例如 GNUReadline),则必须使用此选项,并且可能还必须使用相应的--with-libraries选项。

例子:--with-includes=/opt/gnu/include:/usr/sup/include.

--with-libraries=DIRECTORIES

DIRECTORIES是用于搜索库的以冒号分隔的目录列表。 如果您在非标准位置安装了软件包,您可能必须使用此选项(以及相应的--with-includes选项)。 installed in non-standard locations.

例子:--with-libraries=/opt/gnu/lib:/usr/sup/lib.

--with-system-tzdata=DIRECTORY

PostgreSQL包含它自己的时区数据库,它被用于日期和时间操作。这个时区数据库实际上是和 IANA 时区数据库相兼容的,后者在很多操作系统如 FreeBSD、Linux和Solaris上都有提供,因此再次安装它可能是冗余的。当这个选项被使用时,将不会使用DIRECTORY中系统提供的时区数据库,而是使用包括在 PostgreSQL 源码发布中的时区数据库。 DIRECTORY 必须被指定为一个绝对路径。/usr/share/zoneinfo在某些操作系统上是一个很有可能的路径。注意安装例程将不会检测不匹配或错误的时区数据。如果你使用这个选项,建议你运行回归测试来验证你指定的时区数据能正常地工作在PostgreSQL中。

这个选项主要针对那些很了解他们的目标操作系统的二进制包发布者。使用这个选项主要优点是不管何时当众多本地夏令时规则之一改变时, PostgreSQL 包不需要被升级。另一个优点是如果时区数据库文件在安装时不需要被编译, PostgreSQL 可以被更直接地交叉编译。

--with-extra-version=STRING

STRING附加到 PostgreSQL 版本号。 例如,您可以使用它来标记从未发布的 Git 快照构建的二进制文件或包含带有额外版本字符串的自定义补丁,例如git describe标识符或分发包版本号。

--disable-rpath

不要标记PostgreSQL的可执行文件以表明它们应该在安装的库目录中搜索共享库(请参阅--libdir)。 在大多数平台上,此标记使用库目录的绝对路径,因此如果您稍后重新定位安装将无济于事。但是,您随后需要为可执行文件提供一些其他方式来查找共享库。 通常这需要配置操作系统的动态链接器来搜索库目录; 有关更多详细信息,请参阅本文中第 16.5.1 节。

16.4.1.5. 杂项

使用--with-pgport调整默认端口号是相当常见的,尤其是对于测试版本。 本节中的其他选项仅建议高级用户使用。

--with-pgport=NUMBER

NUMBER设置为服务器和客户端的默认端口号。默认为 5432。 以后可以随时更改端口,但是如果您在此处指定它,那么服务器和客户端都将编译相同的默认值,这会非常方便。 通常选择非默认值的唯一理由是如果您打算在同一台机器上运行多个PostgreSQL服务器。

--with-krb-srvnam=NAME

GSSAPI 使用的 Kerberos 服务主体的默认名称。postgres是默认值。 通常没有理由更改它,除非您是为 Windows 环境构建的,在这种情况下,它必须设置为大写POSTGRES

--with-segsize=SEGSIZE

设置segment size,以千兆字节为单位。大表被分成多个操作系统文件,每个文件的大小等于段的大小。 这避免了许多平台上存在的文件大小限制问题。默认段大小 1 GB 在所有支持的平台上都是安全的。 如果您的操作系统支持largefile(现在大多数都支持),您可以使用更大的段大小。 这有助于减少处理非常大的表时消耗的文件描述符的数量。但请注意不要选择大于您的平台和您打算使用的文件系统支持的值。 您可能希望使用的其他工具,例如tar,也可以设置可用文件大小的限制。 建议(虽然不是绝对要求)此值是 2 的幂。 请注意,更改此值会破坏磁盘数据库兼容性,这意味着您不能使用pg_upgrade升级到具有不同段大小。

--with-blocksize=BLOCKSIZE

设置block size,以千字节为单位。这是表中的存储和 I/O 默认值为 8 KB,适用于大多数情况; 但其他值在特殊情况下可能有用。 该值必须是 1 到 32(千字节)之间的 2 的幂。 请注意,更改此值会破坏磁盘数据库兼容性,这意味着您不能使用pg_upgrade升级到具有不同块大小的构建。

--with-wal-blocksize=BLOCKSIZE

设置WAL block size,以千字节为单位。这是 WAL 日志中的存储和 I/O 单元。 默认值为 8 KB,适用于大多数情况; 但其他值在特殊情况下可能有用。该值必须是 1 到 64(千字节)之间的 2 的幂。 请注意,更改此值会破坏磁盘数据库兼容性,这意味着您不能使用pg_upgrade升级到具有不同 WAL 块大小的构建。

16.4.1.6. Developer Options

本节中的大多数选项仅适用于开发或调试PostgreSQL。 除了--enable-debug之外,不建议将它们用于生产版本,这对于在遇到错误的不幸事件中启用详细的错误报告非常有用。 在支持 DTrace 的平台上,在生产中使用--enable-dtrace也可能是合理的。

在构建将用于在服务器内部开发代码的安装时,建议至少使用选项--enable-debug--enable-cassert

--enable-debug

把所有程序和库以带有调试符号的方式编译。这意味着你可以通过一个调试器运行程序来分析问题。 这样做显著增大了最后安装的可执行文件的大小,并且在非 GCC 的编译器上,这么做通常还要关闭编译器优化, 这些都导致速度的下降。但是,如果有这些符号的话,就可以非常有效地帮助定位可能发生问题的位置。目前,我们只是在你使用 GCC 的情况下才建议在生产安装中使用这个选项。但是如果你正在进行开发工作,或者正在使用 beta 版本,那么你就应该总是打开它。

--enable-cassert

打开在服务器中的assertion检查, 它会检查许多不可能发生的条件。它对于代码开发的用途而言是无价之宝, 不过这些测试可能会显著地降低服务器的速度。并且,打开这个测试不会提高你的系统的稳定性! 这些断言检查并不是按照严重性分类的,因此一些相对无害的小故障也可能导致服务器重启 — 只要它触发了一次断言失败。 目前,我们不推荐在生产环境中使用这个选项,但是如果你在做开发或者在使用 beta 版本的时候应该打开它。

--enable-tap-tests

使用 Perl TAP 工具启用测试。 这需要 Perl 安装和 Perl 模块IPC::Run有关详细信息,请参阅第 32.4 节

--enable-depend

打开自动倚赖性跟踪。如果打开这个选项,那么制作文件(makefile)将设置为在任何头文件被修改的时候都将重新编译所有受影响的目标文件。 如果你在做开发的工作,那么这个选项很有用,但是如果你只是想编译一次并且安装,那么这就是浪费时间。 目前,这个选项只对 GCC 有用。

--enable-coverage

如果使用 GCC,则所有程序和库都使用代码覆盖测试工具进行编译。 运行时,它们会在构建目录中生成带有代码覆盖率指标的文件。 有关详细信息,请参阅第 32.5 节 for more information。此选项仅适用于 GCC 和进行开发工作时。

--enable-profiling

如果使用 GCC,则会编译所有程序和库,以便对其进行分析。 在后端退出时,将创建一个子目录,其中包含包含配置文件数据的gmon.out文件。 此选项仅用于 GCC 和进行开发工作时。

--enable-dtrace

PostgreSQL编译对动态跟踪工具 DTrace 的支持。 详见第 27.5 节。

要指向dtrace程序,必须设置环境变量DTRACE。这通常是必需的,因为dtrace通常被安装在/usr/sbin中,该路径可能不在你的PATH中。

dtrace程序的附加命令行选项可以在环境变量DTRACEFLAGS中指定。在 Solaris 上,要在一个64位二进制中包括 DTrace,你必须指定DTRACEFLAGS="-64"。例如,使用 GCC 编译器:

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

使用 Sun 的编译器:

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

16.4.2. configure 环境变量

除了上面描述的普通命令行选项之外,configure响应许多环境变量。 您可以在configure命令行上指定环境变量,例如:

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

在这种用法中,环境变量与命令行选项几乎没有什么不同。 您还可以预先设置此类变量:

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

这种用法很方便,因为许多程序的配置脚本以类似的方式响应这些变量。

这些环境变量中最常用的是CCCFLAGS。如果你喜欢用那些和configure选取的不同的 C 编译器,那么你可以你的环境变量CC设置为你选择的程序。默认时,只要gcc可以使用,configure将选择它, 或者是该平台的默认(通常是cc)。类似地,你可以用CFLAGS变量覆盖默认编译器标志。

下面是可以以这种方式设置的有效变量的列表:

BISON

Bison程序

CC

C编译器

CFLAGS

传递给 C 编译器的选项

CLANG

clang程序的路径,用于处理使用-with-llvm 进行编译时内联的源代码。

CPP

C 预处理器

CPPFLAGS

传递给 C 预处理器的选项

CXX

C++编译器

CXXFLAGS

传给C++编译器的选项

DTRACE

dtrace程序的位置

DTRACEFLAGS

传递给dtrace程序的选项

FLEX

Flex程序

LDFLAGS

链接可执行程序或共享库时使用的选项

LDFLAGS_EX

只用于链接可执行程序的附加选项

LDFLAGS_SL

只用于链接共享库的附加选项

LLVM_CONFIG

llvm-config程序用于查找 LLVM安装。

MSGFMT

用于本地语言支持的msgfmt程序

PERL

Perl 解释器的全路径名称。这将被用来决定编译 PL/Perl 时的依赖性。

PYTHON

Python 解释器程序。这将被用来决定编译 PL/Python 时的依赖性。另外这里指定的是 Python 2 还是 Python 3 (或者是隐式选择)决定了 PL/Python 语言的哪一种变种将成为可用的。 详见第 45.1 节。 如果未设置,则按以下顺序探测:python python3 python2

TCLSH

Tcl 解释器程序。 这将用于确定构建 PL/Tcl 的依赖关系。 如果未设置,则按此顺序探测以下内容:tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85 tclsh8.4 tclsh84

XML2_CONFIG

用于定位 libxml2 安装的xml2-config程序。

有时候,将编译器标志事后添加到由configure选择的集合中非常有用。 一个重要的例子是,gcc-Werror 选项不能包含在传递给configureCFLAGS中, 因为它会中断许多configure的内置测试。要添加这样的标志, 在运行make时将它们包含在COPT环境变量中。 将COPT的内容添加到由configure设置的 CFLAGSLDFLAGS中。例如,你可以这样做

make COPT='-Werror'

            

或者

export COPT='-Werror'
make

注意

如果在使用 GCC,最好使用至少-O1的优化级别来编译,因为不使用优化(-O0)会禁用某些重要的编译器警告(例如使用未经初始化的变量)。但是,非零的优化级别会使调试更复杂,因为在编译好的代码中步进通常将不能和源代码行一一对应。如果你在尝试调试优化过的代码时觉得困惑,将感兴趣的特定文件使用-O0编译。一种简单的方式是传递一个选项给 makemake PROFILE=-O0 file.o

COPTPROFILE环境变量同样由PostgreSQL makefile实际处理。要使用哪个是一个性能问题,但是开发者的共同习惯是将 PROFILE用于一次性的标识调整,而始终保持设置COPT


PostgreSQL 获取源码
PostgreSQL 安装后设置
温馨提示
下载编程狮App,免费阅读超1000+编程语言教程
取消
确定
目录

PostgreSQL SQL语言

PostgreSQL 服务器管理

PostgreSQL 客户端接口

PostgreSQL 服务器编程

PostgreSQL 参考

PostgreSQL 内部

PostgreSQL 附录

PostgreSQL 参考书目

关闭

MIP.setData({ 'pageTheme' : getCookie('pageTheme') || {'day':true, 'night':false}, 'pageFontSize' : getCookie('pageFontSize') || 20 }); MIP.watch('pageTheme', function(newValue){ setCookie('pageTheme', JSON.stringify(newValue)) }); MIP.watch('pageFontSize', function(newValue){ setCookie('pageFontSize', newValue) }); function setCookie(name, value){ var days = 1; var exp = new Date(); exp.setTime(exp.getTime() + days*24*60*60*1000); document.cookie = name + '=' + value + ';expires=' + exp.toUTCString(); } function getCookie(name){ var reg = new RegExp('(^| )' + name + '=([^;]*)(;|$)'); return document.cookie.match(reg) ? JSON.parse(document.cookie.match(reg)[2]) : null; }