You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a continuation of an issue reported by my colleague: #13725
We're compiling PHP, including OCI8 support, using DeveloperStudio 12.6 and intending to use it as a module with Apache 2.4.58.
Hicham eventually got things to successfully compile and pass a reasonable number of regression tests (i.e., sapi/cli/php works). However, using the corresponding Apache module causes Apache startup (including just doing an "apachectl configtest") to fail with httpd: Syntax error on line 155 of /usr/local/apache_2.4.58-ora_12.2.0-mb/conf/httpd.conf: Can't locate API module structure 'php_module' in file /usr/local/apache_2.4.58-ora_12.2.0-mb/modules/libphp.so: ld.so.1: httpd: php_module: can't find symbol
PHP is configured using (--disable-opcache and --without-pcre-jit used to address issues with previous compilation requests):
I ran "httpd -t" using truss(1); it starts loading the PHP module's dependencies around line 4460 in "php-lib-truss.txt" (Unix-format text file). Nothing looks out of line until about line 4809: After it loads libcryptoutil.so.1, it attempts to open /etc/system.d/crypto:fips-140, receives an ENOENT, closes a file descriptor, prints the "Can't load API module" message, and starts to shut down.
This initially led me to believe that there was a problem with libcryptoutil's initialization. scripts/php-config showed a very long list of libraries, including libsoftcrypto, which is dependent on libcryptoutil. I was uncertain where the "-lsoftcrupto" came from, but found that configure inspects $ORACLE_HOME/lib/sysliblist, and the "mystery" libraries were listed there.
I hacked configure to not inspect Oracle's sysliblist, but the resulting cli executable and Apache module still had the same ldd module as before me trying to ignore sysliblist.
I also ran the cli executable under truss (php-cli-truss.txt; again, Unix format), and I saw that the loading of shared libraries was largely the same as with the Apache module (with some differences). The cli executable, I found, also loads libcryptoutil and tries to open /etc/system.d/crypto:fips-140 as well, but the cli executable just continues with its initialization and works as expected.
So, we're looking for guidance as to how to get PHP 8.1.27's Apache module to load under Solaris 11.
The reason why no one has replied yet is probably because no one of us uses Solaris and no one of us owns SPARC hardware.
The error message you're getting means that the module structure defined here
was not found in the shared object file.
It'd be interesting to know the value of AP_MODULE_DECLARE_DATA.
Can you check with nm whether the php_module symbol is in libphp.so? I guess it's not?
Also, what happens if you remove this and recompile?
Description
This is a continuation of an issue reported by my colleague: #13725
We're compiling PHP, including OCI8 support, using DeveloperStudio 12.6 and intending to use it as a module with Apache 2.4.58.
Hicham eventually got things to successfully compile and pass a reasonable number of regression tests (i.e., sapi/cli/php works). However, using the corresponding Apache module causes Apache startup (including just doing an "apachectl configtest") to fail with
httpd: Syntax error on line 155 of /usr/local/apache_2.4.58-ora_12.2.0-mb/conf/httpd.conf: Can't locate API module structure 'php_module' in file /usr/local/apache_2.4.58-ora_12.2.0-mb/modules/libphp.so: ld.so.1: httpd: php_module: can't find symbol
PHP is configured using (--disable-opcache and --without-pcre-jit used to address issues with previous compilation requests):
As mentioned previously, the CLI version of php successfully runs. The "ldd" output from both the CLI executable and libphp.so is identical:
I ran "httpd -t" using truss(1); it starts loading the PHP module's dependencies around line 4460 in "php-lib-truss.txt" (Unix-format text file). Nothing looks out of line until about line 4809: After it loads libcryptoutil.so.1, it attempts to open /etc/system.d/crypto:fips-140, receives an ENOENT, closes a file descriptor, prints the "Can't load API module" message, and starts to shut down.
This initially led me to believe that there was a problem with libcryptoutil's initialization. scripts/php-config showed a very long list of libraries, including libsoftcrypto, which is dependent on libcryptoutil. I was uncertain where the "-lsoftcrupto" came from, but found that configure inspects $ORACLE_HOME/lib/sysliblist, and the "mystery" libraries were listed there.
I hacked configure to not inspect Oracle's sysliblist, but the resulting cli executable and Apache module still had the same ldd module as before me trying to ignore sysliblist.
I also ran the cli executable under truss (php-cli-truss.txt; again, Unix format), and I saw that the loading of shared libraries was largely the same as with the Apache module (with some differences). The cli executable, I found, also loads libcryptoutil and tries to open /etc/system.d/crypto:fips-140 as well, but the cli executable just continues with its initialization and works as expected.
So, we're looking for guidance as to how to get PHP 8.1.27's Apache module to load under Solaris 11.
php-lib-truss.txt
php-cli-truss.txt
PHP Version
PHP 8.1.27
Operating System
Solaris 11/SPARC
The text was updated successfully, but these errors were encountered: