如何在带有 PHP-FPM 和 NGINX 的 Ubuntu 18.04 LTS 中使用 Oracle Instant Client 启用 OCI8 PHP 扩展？
How does one enable the OCI8 PHP extension, using the Oracle Instant Client, in Ubuntu 18.04 LTS with PHP-FPM and NGINX?
我正在使用 https://launchpad.net/~ondrej/+archive/ubuntu/php 提供的最新 PHP 软件包。
当我构建并安装 OCI8 扩展时，一切似乎都井井有条，但尽管在 PHP-FPM 配置中启用了扩展，但它的存在并未反映在 [=25= 的输出中].
以下要点详细说明了我用来配置、构建和安装 OCI8 PHP 扩展的确切过程：
https://gist.github.com/cbj4074/fa761f60b6f8db431539d76ebfba828e
完全相同的过程和配置在 Ubuntu 16.04 LTS 上运行得非常好，所以在 Ubuntu 18.04 LTS 上似乎存在一些根本差异，无论是操作系统还是 PHP 有问题的包裹。
作为一些重要的（我怀疑与此问题相关的）背景信息，在 Ubuntu 18.04 LTS 上，扩展无法在开箱即用的 CLI 环境中加载，与错误：
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
我是这样解决问题的：
# echo 'LD_LIBRARY_PATH="/opt/oracle/instantclient_12_2"' >> /etc/environment
我认为也许将 LD_LIBRARY_PATH 添加到 PHP-FPM 环境配置可能会解决那里的等效问题：
# echo "env['LD_LIBRARY_PATH'] = /opt/oracle/instantclient_12_2" >> /etc/php/7.2/fpm/pool.d/www.conf
# systemctl restart php7.2-fpm
这确实会导致 LD_LIBRARY_PATH 值，如指定的那样，反映在 phpinfo() 的 Environment 部分（当通过 PHP-FPM + NGINX 并从浏览器请求）和 PHP Variables 部分，如 $_SERVER['LD_LIBRARY_PATH'].
奇怪的是，即使 PHP-FPM 的日志记录设置为 debug，我也看不到我在 CLI 中遇到的 libmql1.so 错误的任何痕迹。 OCI8 扩展加载失败，静默。 display_startup_errors = On in PHP-FPM 也有效 php.ini。
我选择查看 OCI8 扩展是否在同一台服务器上的 Apache 中工作，如果我将 export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 添加到 /etc/apache2/envvars；在缺席的情况下，Apache 在启动时抱怨：
PHP Warning: PHP Startup: Unable to load dynamic library 'oci8.so' (tried: /usr/lib/php/20170718/oci8.so (libmql1.so: cannot open shared object file: No such file or directory), /usr/lib/php/20170718/oci8.so.so (/usr/lib/php/20170718/oci8.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
None 具有 LD_LIBRARY_PATH 的这项业务在 Ubuntu 16.04 LTS 上是必需的，并且根据我在此的观察和关于 的评论，在Ubuntu 17.10 和 Ubuntu 18.04 LTS。
有没有其他人在 Ubuntu 18.04 LTS 上特别尝试过这个？
我在两个不同的 Vagrant 虚拟机上试过这个，laravel/homestead box 6.0.0 和 ubuntu/bionic64 box v20180509.0.0，两者的行为是一样的。
任何其他想法将不胜感激！
编辑 1:
I asked about this issue on the package maintainer's GitHub tracker 并且他认为问题源于未能在编译时设置适当的 RPATH。
我在回复中解释说我正在设置了一个合适的值，但问题仍然关闭。
我确实注意到一个有趣的细节，但是，Ubuntu 18.04 上的编译扩展使用 RUNPATH（而不是 RPATH，它在 Ubuntu 16.04)。如果 PHP-FPM 忽略 RUNPATH，只查找 RPATH，它会解释这种行为。
编辑 2:
这份仍然开放的报告看起来是引入观察到的行为的绝佳候选者：
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
（通过 use RPATH but not RUNPATH? 的评论发现）
编辑 3:
根据评论者的建议，我重新检查了在构建扩展之前更新 ld 配置并解决了问题！我以前试过这个，但一定是在构建尝试之间忽略了一些东西：
# echo /opt/oracle/instantclient_12_2 > /etc/ld.so.conf.d/oracle-instantclient.conf
# ldconfig
我仍然不知道为什么 LD_LIBRARY_PATH 在这种情况下不能正常工作，但是将 Instant Client 库路径添加到链接器配置似乎是一个更好的方法。
编辑 4:
我在之前的编辑中说过，修改 ldconfig 是一种更好的方法，但后来意识到（根据评论者的好建议）这样做会导致不良的库冲突，因为效果是系统-宽
事后看来，通过 LD_LIBRARY_PATH 将运行时库链接修改限制在执行环境中，从而最大限度地减少 "collateral damage" 是有意义的。因此，我有动力确定为什么这不适用于 Ubuntu 18.04 LTS。
我觉得我已经确定 PHP-FPM 守护进程在 Ubuntu 上忽略了 LD_LIBRARY_PATH（并且从那以后至少 Ubuntu 16.04 LTS；见评论解释）。
ld.so(8) 联机帮助页指出（与搜索运行时库路径的顺序相关）：
Using the environment variable LD_LIBRARY_PATH (unless the executable is being run in secure-execution mode; see below). [sic] in which case it is ignored.
到目前为止，我想不出还有什么其他原因可以忽略该路径。 secure-execution mode，同一份文件说：
Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary
should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is exe‐
cuted in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may
have a nonzero value for various reasons, including:
* The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of
executing a set-user-ID or set-group-ID program.
* A process with a non-root user ID executed a binary that conferred capabilities to the process.
* A nonzero value may have been set by a Linux Security Module.
首先，安全执行模式似乎没有生效，因为 PHP 可执行文件不显示此标志（AT_SECURE 是 0）：
LD_SHOW_AUXV=1 /usr/sbin/php-fpm7.1 -daemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf
AT_SYSINFO_EHDR: 0x7ffc569e1000
AT_HWCAP: 178bfbff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x55ceab0c4040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x7f823c77f000
AT_FLAGS: 0x0
AT_ENTRY: 0x55ceab19e360
AT_UID: 0
AT_EUID: 0
AT_GID: 0
AT_EGID: 0
AT_SECURE: 0
AT_RANDOM: 0x7ffc56962349
AT_HWCAP2: 0x0
AT_EXECFN: /usr/sbin/php-fpm7.1
AT_PLATFORM: x86_64
我想到子 FPM 池进程可能表现出不同的 AT_SECURE 值，但 PHP-FPM 守护进程本身以及任何子进程的输出是相同的。 parent 和 children 都有以下值：
# od -t d8 /proc/851/auxv
0000000 33 140722944548864
0000020 16 395049983
0000040 6 4096
0000060 17 100
0000100 3 93903778242624
0000120 4 56
0000140 5 9
0000160 7 140365152313344
0000200 8 0
0000220 9 93903779136352
0000240 11 0
0000260 12 0
0000300 13 0
0000320 14 0
0000340 23 0
0000360 25 140722944193929
0000400 26 0
0000420 31 140722944196579
0000440 15 140722944193945
0000460 0 0
其次，none 这些原因似乎适用，原因如下：
1) 没有迹象表明 PHP-FPM 或其子进程具有不同的真实有效用户或组 ID（感谢 https://unix.stackexchange.com/a/202359 此命令）：
# ps -e -o user= -o ruser= | awk ' != '
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
# ps -e -o group= -o rgroup= | awk ' != '
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
2) 有问题的二进制文件没有任何功能（以下命令不产生输出）：
# getcap /usr/lib/php/20170718/oci8.so
# getcap -r /opt/oracle/instantclient_12_2/
3) 我已经确保 AppArmor 被禁用（无论如何它没有影响 PHP-FPM 的策略）：
# systemctl disable apparmor
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apparmor
# reboot
# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
那么，如果不是出于上述任何原因，为什么 PHP-FPM 会忽略 LD_LIBRARY_PATH？
编辑 5（解决方案）：
一位精明的评论者 @vinc17 指出，在系统 运行 systemd 上，环境变量（例如 LD_LIBRARY_PATH 不一定传播到通过以下方式启动的进程一个systemd单位。
换句话说，PHP-FPM 不是 "ignoring" LD_LIBRARY_PATH，而是没有传送到进程。并且尝试在 PHP-FPM 配置中设置 LD_LIBRARY_PATH 是徒劳的，因为现在对这个值做任何有用的事情都太晚了。
根据这个建议，我想到在 systemd 上下文中设置 LD_LIBRARY_PATH，即在启动 PHP-FPM 守护程序的单元文件中（ s), 在这种情况下 PHP-FPM 成功加载 OCI8 扩展。
不用说，我们想避免编辑包维护者的文件（以避免在未来升级时发生冲突），所以我们改为扩展它：
# mkdir /etc/systemd/system/php7.1-fpm.service.d
# touch /etc/systemd/system/php7.1-fpm.service.d/environment.conf
我们向该文件添加以下内容：
[Service]
Environment=LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
并使更改生效：
# systemctl daemon-reload
# systemctl restart php7.1-fpm
有关解决多个共同安装的 PHP 版本的更完整示例，请参阅我的 post https://github.com/oerdnj/deb.sury.org/issues/865#issuecomment-395441936。
首先，Debian bug 859732 是一个完全不同的问题（我什至会说一个相反的问题）：对于这个错误，搜索路径中存在库的多个版本（一个在 LD_LIBRARY_PATH 和 运行 路径指定的某个目录中的不同目录），但动态链接器选择了错误的目录。
在您的情况下，问题是在搜索路径中找不到请求的库。另请注意，在您的情况下，PHP 似乎试图打开库（通过 dlopen？），因为消息以 "PHP Warning:" 开头。但是，这些机制似乎与通常的动态链接相同。
安装库后，您至少需要以下之一：
- 如果库已安装在默认搜索的目录中，则没有什么特别之处。既然你得到一个错误，这不是你的情况。
- 在 运行 路径中提供目录，必须在需要该库的软件编译时指定该目录。问题是在 Linux 下，构建工具并没有按照标准完成，而且在不破坏其他东西的情况下正确地完成它可能很复杂。但是，在
dlopen 的上下文中，软件（此处为 PHP）可能已经设置了一个可以称为 "plugin search path" 的内容，您可以将库放在其中。
- 提供
LD_LIBRARY_PATH 中的目录。这是您尝试过的方法，但您的 LD_LIBRARY_PATH 似乎不正确。库通常安装在名为 lib（或在特定情况下为 lib32 或 lib64）的子目录中。所以，export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 似乎是错误的。搜索库 oci8.so 的完整路径名，只取此路径名的目录部分 LD_LIBRARY_PATH.
注意：strace 可能有助于查看考虑搜索库的目录。 编辑： ldd 和 objdump -p 是其他有用的工具，可用于查找搜索路径的情况。
编辑 2: 选择使用 运行 路径时要注意的另一点是，使用 RPATH 时会发现间接库依赖项，但是不是在使用 RUNPATH 时（因此，在后一种情况下，如果所有依赖项 also 依赖于其他库，则它们也需要具有 运行 路径，以便所有库无需求助于 LD_LIBRARY_PATH) 即可找到。 ld.so(8) 手册页的最新版本中记录了这一点：
Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree.
这可能就是为什么在不使用 LD_LIBRARY_PATH 的情况下，它适用于 16.04（其中使用 RPATH）而不适用于 18.04（其中使用 RUNPATH）。
我正在使用 https://launchpad.net/~ondrej/+archive/ubuntu/php 提供的最新 PHP 软件包。
当我构建并安装 OCI8 扩展时，一切似乎都井井有条，但尽管在 PHP-FPM 配置中启用了扩展，但它的存在并未反映在 [=25= 的输出中].
以下要点详细说明了我用来配置、构建和安装 OCI8 PHP 扩展的确切过程：
https://gist.github.com/cbj4074/fa761f60b6f8db431539d76ebfba828e
完全相同的过程和配置在 Ubuntu 16.04 LTS 上运行得非常好，所以在 Ubuntu 18.04 LTS 上似乎存在一些根本差异，无论是操作系统还是 PHP 有问题的包裹。
作为一些重要的（我怀疑与此问题相关的）背景信息，在 Ubuntu 18.04 LTS 上，扩展无法在开箱即用的 CLI 环境中加载，与错误：
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
我是这样解决问题的：
# echo 'LD_LIBRARY_PATH="/opt/oracle/instantclient_12_2"' >> /etc/environment
我认为也许将 LD_LIBRARY_PATH 添加到 PHP-FPM 环境配置可能会解决那里的等效问题：
# echo "env['LD_LIBRARY_PATH'] = /opt/oracle/instantclient_12_2" >> /etc/php/7.2/fpm/pool.d/www.conf
# systemctl restart php7.2-fpm
这确实会导致 LD_LIBRARY_PATH 值，如指定的那样，反映在 phpinfo() 的 Environment 部分（当通过 PHP-FPM + NGINX 并从浏览器请求）和 PHP Variables 部分，如 $_SERVER['LD_LIBRARY_PATH'].
奇怪的是，即使 PHP-FPM 的日志记录设置为 debug，我也看不到我在 CLI 中遇到的 libmql1.so 错误的任何痕迹。 OCI8 扩展加载失败，静默。 display_startup_errors = On in PHP-FPM 也有效 php.ini。
我选择查看 OCI8 扩展是否在同一台服务器上的 Apache 中工作，如果我将 export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 添加到 /etc/apache2/envvars；在缺席的情况下，Apache 在启动时抱怨：
PHP Warning: PHP Startup: Unable to load dynamic library 'oci8.so' (tried: /usr/lib/php/20170718/oci8.so (libmql1.so: cannot open shared object file: No such file or directory), /usr/lib/php/20170718/oci8.so.so (/usr/lib/php/20170718/oci8.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
None 具有 LD_LIBRARY_PATH 的这项业务在 Ubuntu 16.04 LTS 上是必需的，并且根据我在此的观察和关于
有没有其他人在 Ubuntu 18.04 LTS 上特别尝试过这个？
我在两个不同的 Vagrant 虚拟机上试过这个，laravel/homestead box 6.0.0 和 ubuntu/bionic64 box v20180509.0.0，两者的行为是一样的。
任何其他想法将不胜感激！
编辑 1:
I asked about this issue on the package maintainer's GitHub tracker 并且他认为问题源于未能在编译时设置适当的 RPATH。
我在回复中解释说我正在设置了一个合适的值，但问题仍然关闭。
我确实注意到一个有趣的细节，但是，Ubuntu 18.04 上的编译扩展使用 RUNPATH（而不是 RPATH，它在 Ubuntu 16.04)。如果 PHP-FPM 忽略 RUNPATH，只查找 RPATH，它会解释这种行为。
编辑 2:
这份仍然开放的报告看起来是引入观察到的行为的绝佳候选者：
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
（通过 use RPATH but not RUNPATH? 的评论发现）
编辑 3:
根据评论者的建议，我重新检查了在构建扩展之前更新 ld 配置并解决了问题！我以前试过这个，但一定是在构建尝试之间忽略了一些东西：
# echo /opt/oracle/instantclient_12_2 > /etc/ld.so.conf.d/oracle-instantclient.conf
# ldconfig
我仍然不知道为什么 LD_LIBRARY_PATH 在这种情况下不能正常工作，但是将 Instant Client 库路径添加到链接器配置似乎是一个更好的方法。
编辑 4:
我在之前的编辑中说过，修改 ldconfig 是一种更好的方法，但后来意识到（根据评论者的好建议）这样做会导致不良的库冲突，因为效果是系统-宽
事后看来，通过 LD_LIBRARY_PATH 将运行时库链接修改限制在执行环境中，从而最大限度地减少 "collateral damage" 是有意义的。因此，我有动力确定为什么这不适用于 Ubuntu 18.04 LTS。
我觉得我已经确定 PHP-FPM 守护进程在 Ubuntu 上忽略了 LD_LIBRARY_PATH（并且从那以后至少 Ubuntu 16.04 LTS；见评论解释）。
ld.so(8) 联机帮助页指出（与搜索运行时库路径的顺序相关）：
Using the environment variable LD_LIBRARY_PATH (unless the executable is being run in secure-execution mode; see below). [sic] in which case it is ignored.
到目前为止，我想不出还有什么其他原因可以忽略该路径。 secure-execution mode，同一份文件说：
Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary
should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is exe‐
cuted in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may
have a nonzero value for various reasons, including:
* The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of
executing a set-user-ID or set-group-ID program.
* A process with a non-root user ID executed a binary that conferred capabilities to the process.
* A nonzero value may have been set by a Linux Security Module.
首先，安全执行模式似乎没有生效，因为 PHP 可执行文件不显示此标志（AT_SECURE 是 0）：
LD_SHOW_AUXV=1 /usr/sbin/php-fpm7.1 -daemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf
AT_SYSINFO_EHDR: 0x7ffc569e1000
AT_HWCAP: 178bfbff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x55ceab0c4040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x7f823c77f000
AT_FLAGS: 0x0
AT_ENTRY: 0x55ceab19e360
AT_UID: 0
AT_EUID: 0
AT_GID: 0
AT_EGID: 0
AT_SECURE: 0
AT_RANDOM: 0x7ffc56962349
AT_HWCAP2: 0x0
AT_EXECFN: /usr/sbin/php-fpm7.1
AT_PLATFORM: x86_64
我想到子 FPM 池进程可能表现出不同的 AT_SECURE 值，但 PHP-FPM 守护进程本身以及任何子进程的输出是相同的。 parent 和 children 都有以下值：
# od -t d8 /proc/851/auxv
0000000 33 140722944548864
0000020 16 395049983
0000040 6 4096
0000060 17 100
0000100 3 93903778242624
0000120 4 56
0000140 5 9
0000160 7 140365152313344
0000200 8 0
0000220 9 93903779136352
0000240 11 0
0000260 12 0
0000300 13 0
0000320 14 0
0000340 23 0
0000360 25 140722944193929
0000400 26 0
0000420 31 140722944196579
0000440 15 140722944193945
0000460 0 0
其次，none 这些原因似乎适用，原因如下：
1) 没有迹象表明 PHP-FPM 或其子进程具有不同的真实有效用户或组 ID（感谢 https://unix.stackexchange.com/a/202359 此命令）：
# ps -e -o user= -o ruser= | awk ' != '
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
# ps -e -o group= -o rgroup= | awk ' != '
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
2) 有问题的二进制文件没有任何功能（以下命令不产生输出）：
# getcap /usr/lib/php/20170718/oci8.so
# getcap -r /opt/oracle/instantclient_12_2/
3) 我已经确保 AppArmor 被禁用（无论如何它没有影响 PHP-FPM 的策略）：
# systemctl disable apparmor
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apparmor
# reboot
# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
那么，如果不是出于上述任何原因，为什么 PHP-FPM 会忽略 LD_LIBRARY_PATH？
编辑 5（解决方案）：
一位精明的评论者 @vinc17 指出，在系统 运行 systemd 上，环境变量（例如 LD_LIBRARY_PATH 不一定传播到通过以下方式启动的进程一个systemd单位。
换句话说，PHP-FPM 不是 "ignoring" LD_LIBRARY_PATH，而是没有传送到进程。并且尝试在 PHP-FPM 配置中设置 LD_LIBRARY_PATH 是徒劳的，因为现在对这个值做任何有用的事情都太晚了。
根据这个建议，我想到在 systemd 上下文中设置 LD_LIBRARY_PATH，即在启动 PHP-FPM 守护程序的单元文件中（ s), 在这种情况下 PHP-FPM 成功加载 OCI8 扩展。
不用说，我们想避免编辑包维护者的文件（以避免在未来升级时发生冲突），所以我们改为扩展它：
# mkdir /etc/systemd/system/php7.1-fpm.service.d
# touch /etc/systemd/system/php7.1-fpm.service.d/environment.conf
我们向该文件添加以下内容：
[Service]
Environment=LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
并使更改生效：
# systemctl daemon-reload
# systemctl restart php7.1-fpm
有关解决多个共同安装的 PHP 版本的更完整示例，请参阅我的 post https://github.com/oerdnj/deb.sury.org/issues/865#issuecomment-395441936。
首先，Debian bug 859732 是一个完全不同的问题（我什至会说一个相反的问题）：对于这个错误，搜索路径中存在库的多个版本（一个在 LD_LIBRARY_PATH 和 运行 路径指定的某个目录中的不同目录），但动态链接器选择了错误的目录。
在您的情况下，问题是在搜索路径中找不到请求的库。另请注意，在您的情况下，PHP 似乎试图打开库（通过 dlopen？），因为消息以 "PHP Warning:" 开头。但是，这些机制似乎与通常的动态链接相同。
安装库后，您至少需要以下之一：
- 如果库已安装在默认搜索的目录中，则没有什么特别之处。既然你得到一个错误，这不是你的情况。
- 在 运行 路径中提供目录，必须在需要该库的软件编译时指定该目录。问题是在 Linux 下，构建工具并没有按照标准完成，而且在不破坏其他东西的情况下正确地完成它可能很复杂。但是，在
dlopen的上下文中，软件（此处为 PHP）可能已经设置了一个可以称为 "plugin search path" 的内容，您可以将库放在其中。 - 提供
LD_LIBRARY_PATH中的目录。这是您尝试过的方法，但您的LD_LIBRARY_PATH似乎不正确。库通常安装在名为lib（或在特定情况下为lib32或lib64）的子目录中。所以，export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2似乎是错误的。搜索库oci8.so的完整路径名，只取此路径名的目录部分LD_LIBRARY_PATH.
注意：strace 可能有助于查看考虑搜索库的目录。 编辑： ldd 和 objdump -p 是其他有用的工具，可用于查找搜索路径的情况。
编辑 2: 选择使用 运行 路径时要注意的另一点是，使用 RPATH 时会发现间接库依赖项，但是不是在使用 RUNPATH 时（因此，在后一种情况下，如果所有依赖项 also 依赖于其他库，则它们也需要具有 运行 路径，以便所有库无需求助于 LD_LIBRARY_PATH) 即可找到。 ld.so(8) 手册页的最新版本中记录了这一点：
Using the directories specified in the
DT_RUNPATHdynamic section attribute of the binary if present. Such directories are searched only to find those objects required byDT_NEEDED(direct dependencies) entries and do not apply to those objects' children, which must themselves have their ownDT_RUNPATHentries. This is unlikeDT_RPATH, which is applied to searches for all children in the dependency tree.
这可能就是为什么在不使用 LD_LIBRARY_PATH 的情况下，它适用于 16.04（其中使用 RPATH）而不适用于 18.04（其中使用 RUNPATH）。