Migrate from PHP v7.3.6 to v8.3.8 on Solaris 10 from source (errors)

[charlie333333]

Description

The following code:

$ ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-zlib=yes --with-openssl --with-iconv=/usr/local/lib --with-openssl-dir=/usr/local/ssl --enable-shared --with-oci8=shared,/cbs/oracle/product/ATMclnt32a --enable-sigchild --enable-sockets --without-pcre-jit --without-sqlite3 --without-pdo-sqlite --disable-ipv6 --with-pear=/usr/local/lib/php

We are using Solaris 10 with Apache and Oracle SQL.

Resulted in this output:

Undefined first referenced
symbol in file
gzseek64 ext/zlib/zlib_fopen_wrapper.o
getrandom ext_random/csprng.o
php_register_internal_entensions main/main.o
ld: fatal: symbol referencing errors. No output written to sapi/cli/php
Makefile:286: recipe for target 'sapi/cli/php' failed

We then used the same environment to build v7.3.6 and that was successful, using the same parameters. Are there any module versions that are no longer supported for PHP v8? We are using GCC v4.

Many thanks.

PHP Version

PHP 8.3.8

Operating System

Solaris 10

[devnexen]

Hi and thanks for your report. That is quite the jump !
getrandom (and its sibling getentropy) is not supported on solaris 10 (11.3 I believe).
Seems also an old version of zlib.
What is the version of gcc precisely ? e.g. between 4.2 and 4.8 there is good bench of new features better support of C99 and so on.
Did you try php, let's say any 8.1 release ?

[charlie333333]

Thanks for the quick response @devnexen!

We are using gcc (GCC) 4.7.2.

We can try v8.1 if you think that will help, but obviously that will only give us a shorter period of active support.

Module versions are as follows:

ZLIB - 1.2.0.4
OPENSSL - 1.0.2
LIBXML - 2.9.0

Let me know if you need anything else.

[devnexen]

The getrandom issue could be eventually fixed with getrandom symbol check (AFAIK getrandom, as a function, is only a "concern" on linux so no need to change the existing logic for this one). However for the zlib issue, it is delicate on solaris, e.g. a 64 bits os running 32 bits binaries by default also 1.2.0.4 seems really old (2003). As far as I know, it would need a proper 64 bits version of zlib/having large file support enabled (i.e. -D_FILE_OFFSET_BITS=64 in CFLAGS)

[charlie333333]

OK thanks.

These are the current CFLAGS...

-std=gnu99 -fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -L/cbs/oracle/product/ATMclnt32a/lib -R/cbs/oracle/product/ATMclnt32a/ -L/usr/lib -R/usr/lib

[devnexen]

Maybe that s why the linkage issue with zlib, large file are enabled in the php build thus expecting gzseek64 instead of gzseek but isn't in the zlib side. But that s a hypothesis, I do not know that much zlib :) Anyhow, I ll propose a fix for the random extension shortly.

[cmb69]

OPENSSL - 1.0.2

If I remember correctly, PHP requires at least OpenSSL 1.1 for a couple of years.

[charlie333333]

Thanks @devnexen and @cmb69.

We have been going around in circles for a couple of weeks on this, so all help is very much appreciated.

[devnexen]

Yes cmb69 gives a good point. If possible, if I were in your shoes, I would likely compile dependencies (openssl, zlib, ...) from source. Building in such old environments will become increasingly difficult over time I m afraid.

[charlie333333]

Thanks. Should we be moving all dependencies to the most up to date version? Or will that likely not support Solaris 10?

We currently don't use a package manager and all is done from source.

[devnexen]

Not necessarily the last versions (and some dependencies might just not compile anyway) but the best solaris 10 can support should work in theory.

[charlie333333]

OK great - thanks.

I will use unixpackages.com to verify the latest dependencies for Sol 10 and download if required.

Is there anything else you would suggest I do?

I will give an early release of PHP v8 a try too.

[devnexen]

Nothing for the moment let us know once you hit the first wall. Cheers.

[charlie333333]

Hi @devnexen,

We have included config.m4, random.c and csprng.c int the /ext/random directory and tried again...

We get the following error...

ld: fatal: symbol 'php_random_bytes' is multiply-defined:
(file ext/random/random.o type=FUNC; file ext/random/csprng.o type=FUNC);
ld: fatal: symbol 'php_random_int' is multiply-defined:
(file ext/random/random.o type=FUNC; file ext/random/csprng.o type=FUNC);
ld: fatal: file processing errors. No output written to sapi/cli/php
collect2: error: ld returned 1 exit status
Makefile:284: recipe for target 'sapi/cli/php' failed
make: *** [sapi/cli/php] Error 1
make: *** Waiting for unfinished jobs....

We still see the zlib error, with a 32 bit v1.2.11. We have configured without zlib for the time being and are unable to use a 64 bit module without a lot of legacy errors.

Many thanks.

[devnexen]

it might be best if you start fresh with the git repo for example, branch PHP-8.3.
I propose, for now, we try to build without --with-zlib which we can try to sort out separately if that s fine with you ?

[charlie333333]

OK thanks @devnexen.

We will try that shortly. Thanks.

[charlie333333]

Hi @devnexen, We ran into lots of errors with bison and re2c versions. We also noticed that the git repo branch had a lot less Zend modules than from the PHP site, which caused issues.

We are now struggling to get autoconf to work to create the configure script. This script is supplied with the modules on the PHP site.

We plan on trying PHP v8.0 tomorrow (both git repo and PHP site).

[devnexen]

Hi @devnexen, We ran into lots of errors with bison and re2c versions. We also noticed that the git repo branch had a lot less Zend modules than from the PHP site, which caused issues.

We are now struggling to get autoconf to work to create the configure script. This script is supplied with the modules on the PHP site.

Note that indeed configure is not present on the git repo, ./buildconf needs to be called prior.

We plan on trying PHP v8.0 tomorrow (both git repo and PHP site).

[charlie333333]

Thanks @devnexen,

We will try the buildconf shortly.

We have reverted to v8.0 and it gets a lot further. We are getting the following error...

Undefined first referenced
symbol in file
php_register_internal_entensions main/main.o
ld: fatal: symbol referencing errors. No output written to sapi/cli/php
Makefile:286: recipe for target 'sapi/cli/php' failed

Any ideas?

[cmb69]

php_register_internal_entensions main/main.o

Do you mean php_register_internal_extensions? If so, your build is likely broken; you need to call ./buildconf prior to ./configure.

[charlie333333]

Yes sorry. This was using the PHP v8.0 website software. The configure command was already supplied.

[cmb69]

This was using the PHP v8.0 website software. The configure command was already supplied.

Ah, right. ./configure is supposed to create the file main/internal_functions.c (from main/internal_functions.c.in). Has that file been created for you?

[devnexen]

Nice to hear ! is there anything else to explore or can we close it ?

[charlie333333]

We can close it, thanks.

[charlie333333]

Hi Gents,

Am I okay to use this thread to ask for help?

Although we have got one server working completely, we are still seeing the symbol __bswapsi2: referenced symbol not found issue on the other.

We have recompiled using gcc 4.7.2 and then redone PHP 8.1.29 but no luck.

Is there anything that you can suggest to help? It is the last ticket before the project is complete.

[devnexen]

are php/apache dependencies also compiled with gcc 4.7.2 ?

[charlie333333]

We have this in the PHP config.log...

configure:4788: checking for gcc
configure:4809: found /usr/local/gcc4/bin/gcc
configure:4821: result: gcc
configure:4852: checking for C compiler version
configure:4861: gcc --version >&5
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And this in the Apache config.log...

configure:5060: checking for gcc
configure:5087: result: gcc
configure:5316: checking for C compiler version
configure:5325: gcc --version >&5
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:5336: $? = 0
configure:5325: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc4/libexec/gcc/sparc-sun-solaris2.10/4.7.2/lto-wrapper

This is our error when we start Apache...

httpd: Syntax error on line 152 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/libphp.so into server: ld.so.1: httpd: fatal: relocation error: file /usr/local/apache2/modules/libphp.so: symbol __bswapsi2: referenced symbol not found

[devnexen]

is the output of this command the same at your other server ?

[charlie333333]

Yes - they are identical and the libgcc_s.so.1 that it points at is the same.

/usr/local/lib
garnet(136) $ ls -l *gcc*
lrwxrwxrwx   1 root     root          13 Jun  5  2014 libgcc_s.so -> libgcc_s.so.1
-rw-r--r--   1 bin      bin       168580 Sep  5  2006 libgcc_s.so.1

[charlie333333]

This is on the working server...

garnet(167) $ ls -l *gcc*
lrwxrwxrwx   1 root     root          13 Jun  5  2014 libgcc_s.so -> libgcc_s.so.1
-rw-r--r--   1 bin      bin       168580 Sep  5  2006 libgcc_s.so.1
/usr/local/lib
garnet(168) $ cd ../gcc4/lib
/usr/local/gcc4/lib
garnet(169) $ ls -l *gcc*
-rw-r--r--   1 bin      bin       278868 May  9  2013 libgcc_s.so
-rw-r--r--   1 bin      bin       278868 May  9  2013 libgcc_s.so.1

Not sure how to tell which one it uses. It looks to be the old one looking this...

garnet(170) $ ldd /usr/local/apache2/modules/libphp.so
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        librt.so.1 =>    /usr/lib/librt.so.1
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libm.so.2 =>     /usr/lib/libm.so.2
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libssl.so.1.0.0 =>       /usr/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>    /usr/lib/libcrypto.so.1.0.0
        libz.so =>       /usr/local/lib/libz.so
        libxml2.so.2 =>  /usr/local/lib/libxml2.so.2
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libscf.so.1 =>   /lib/libscf.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        /lib/libm/libm_hwcap1.so.2
        /platform/sun4v/lib/libc_psr.so.1
        /platform/sun4v/lib/libmd_psr.so.1

[devnexen]

Seems to be the issue indeed. What about cleaning the php build (ie make distclean).

And setting the following :

export LDFLAGS="-L/usr/local/gcc4/lib -Wl,-rpath,/usr/local/gcc4/lib <your other usual settings>"

[charlie333333]

Sorry - Garnet is the working server.

So both servers are looking at the old version of libgcc_s.so_1 according to the ldd command.

[devnexen]

Is there LD_LIBRARY_PATH set in the working server ?

[charlie333333]

I have just spotted that.

Working server..

if test "x$LD_LIBRARY_PATH" != "x" ; then
  LD_LIBRARY_PATH="/usr/local/apache2/lib:/cbs/oracle/product/ATMclnt32a/lib:/usr/local/gcc4/lib"
else
  LD_LIBRARY_PATH="/usr/local/apache2/lib"
fi
export LD_LIBRARY_PATH
ORACLE_HOME=/cbs/oracle/product/ATMclnt32a
export ORACLE_HOME

Problematic server ...

if test "x$LD_LIBRARY_PATH" != "x" ; then
  LD_LIBRARY_PATH="/usr/local/apache2/lib:$LD_LIBRARY_PATH"
else
  LD_LIBRARY_PATH="/usr/local/apache2/lib"
fi
export LD_LIBRARY_PATH
#
#ORACLE_HOME=/cbs/oracle/product/ATMclnt32
#export ORACLE_HOME

I can see that we set the PATH in the Apache configure command, but we don't set a LD_LIBRARY_PATH.

For info, we haven't upgraded the working Apache (hence why it is still working).

[charlie333333]

Great thanks - the envvars setup worked.

However, on our final server (Production), we use SSL inside Apache. After re-compiling Apache 2.4.41 with GCC 4.7.2 and recompiling PHP 8.1.29 again, we get the following error when starting Apache...

httpd: Syntax error on line 128 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/mod_ssl.so into server: ld.so.1: httpd: fatal: relocation error: file /usr/local/apache2/modules/mod_ssl.so: symbol EC_GROUP_get_curve_name: referenced symbol not found

This is from the PHP info...

OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.0.2zi  1 Aug 2023
OpenSSL Header Version => OpenSSL 1.0.2zi  1 Aug 2023
Openssl default config => /etc/openssl/openssl.cnf

We haven't changed anything else, and our backup server works (using PHP 7.3.6).

Although I spotted this on the working server...

OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 1.0.2zi  1 Aug 2023
OpenSSL Header Version => OpenSSL 1.0.2u  20 Dec 2019
Openssl default config => /etc/openssl/openssl.cnf

Beer in the post if we manage to sort this last one out.

[devnexen]

There might be more than once SSL installed in the server, maybe when you compiled apache the ssl module was supposed to be linked to version B but then load older version A. ldd /usr/local/apache2/modules/mod_ssl.so might give a beginning of an answer. Also the working server

OpenSSL Library Version => OpenSSL 1.0.2zi  1 Aug 2023
OpenSSL Header Version => OpenSSL 1.0.2u  20 Dec 2019

does not look right.

[charlie333333]

So I can see that the dependencies libssl and libcrypto are pointing at a couple of different versions from the /usr/local/ssl directory that we recompiled Apache with...

garnet(163) $ ldd mod_ssl.so
        libssl.so.1.0.0 =>       /usr/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>    /usr/lib/libcrypto.so.1.0.0
        libuuid.so.1 =>  /lib/libuuid.so.1
        libsendfile.so.1 =>      /lib/libsendfile.so.1
        librt.so.1 =>    /lib/librt.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libpthread.so.1 =>       /lib/libpthread.so.1
        libc.so.1 =>     /lib/libc.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libscf.so.1 =>   /lib/libscf.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libm.so.2 =>     /lib/libm.so.2
        /lib/libm/libm_hwcap1.so.2
        /platform/sun4v/lib/libc_psr.so.1
        /platform/sun4v/lib/libmd_psr.so.1

/usr/lib
garnet(167) $ ls -l *libssl*
lrwxrwxrwx   1 root     root          17 Jun  9  2016 libssl.so -> ./libssl.so.1.0.0
-rwxr-xr-x   1 root     bin       433744 Oct  2  2023 libssl.so.1.0.0

/usr/local/ssl/lib
garnet(171) $ ls -l
total 16433
drwxr-xr-x   2 root     bin           14 Dec  8  2014 engines
-rw-r--r--   1 root     bin      2780470 Oct 16  2014 libcrypto.a
lrwxrwxrwx   1 root     root          18 Dec  8  2014 libcrypto.so -> libcrypto.so.1.0.0
-r-xr-xr-x   1 root     bin      1593404 Oct 16  2014 libcrypto.so.0.9.8
-r-xr-xr-x   1 root     bin      1883063 Oct 16  2014 libcrypto.so.1.0.0
-rw-r--r--   1 root     bin       168580 Oct 16  2014 libgcc_s.so.1
-rw-r--r--   1 root     bin       553148 Oct 16  2014 libssl.a
lrwxrwxrwx   1 root     root          15 Dec  8  2014 libssl.so -> libssl.so.1.0.0
-r-xr-xr-x   1 root     bin       346870 Oct 16  2014 libssl.so.0.9.8
-r-xr-xr-x   1 root     bin       423431 Oct 16  2014 libssl.so.1.0.0

They were just part of an OS patch, maybe rename them and try a recompile?

[devnexen]

Are all (custom) dependencies located in /usr/local or does it draw also in /usr ?

[charlie333333]

I can't see anything of interest in /usr apart from the /apache2, /local and /lib directories.

[devnexen]

would be helpful to review with which flags apache had been built, CFLAGS, LDFLAGS, configure step ... maybe something is missing (e.g. rpath)

[charlie333333]

We have got passed this error because our path was incorrect (line 128)...

httpd: Syntax error on line 128 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/mod_ssl.so into server: ld.so.1: httpd: fatal: relocation error: file /usr/local/apache2/modules/mod_ssl.so: symbol EC_GROUP_get_curve_name: referenced symbol not found

/usr/local/apache2/modules
garnet(148) $ ldd mod_ssl*

        libssl.so.1.0.0 =>       /usr/local/ssl/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>    /usr/local/ssl/lib/libcrypto.so.1.0.0
        libuuid.so.1 =>  /lib/libuuid.so.1
        libsendfile.so.1 =>      /lib/libsendfile.so.1
        librt.so.1 =>    /lib/librt.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libpthread.so.1 =>       /lib/libpthread.so.1
        libc.so.1 =>     /lib/libc.so.1
        libgcc_s.so.1 =>         /usr/local/gcc4/lib/libgcc_s.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libscf.so.1 =>   /lib/libscf.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libm.so.2 =>     /lib/libm.so.2
        /lib/libm/libm_hwcap1.so.2
        /platform/sun4v/lib/libc_psr.so.1
        /platform/sun4v/lib/libmd_psr.so.1

/usr/local/apache2/modules
garnet(150) $ ldd libphp.so

        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        librt.so.1 =>    /usr/lib/librt.so.1
        libldap-2.4.so.2 =>      /usr/local/lib/libldap-2.4.so.2
        libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
        libm.so.2 =>     /usr/lib/libm.so.2
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libssl.so.1.0.0 =>       /usr/local/ssl/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 =>    /usr/local/ssl/lib/libcrypto.so.1.0.0
        libz.so =>       /usr/local/lib/libz.so
        libxml2.so.2 =>  /usr/local/lib/libxml2.so.2
        libgcc_s.so.1 =>         /usr/local/gcc4/lib/libgcc_s.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        liblber-2.4.so.2 =>      /usr/local/lib/liblber-2.4.so.2
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libsasl2.so.3 =>         /usr/local/lib/libsasl2.so.3
        libmp.so.2 =>    /lib/libmp.so.2
        libscf.so.1 =>   /lib/libscf.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        /lib/libm/libm_hwcap1.so.2
        /platform/sun4v/lib/libc_psr.so.1
        /platform/sun4v/lib/libmd_psr.so.1

However, it looks like something is not quite right in PHP 8.1.29 to run the SSL functionality...

httpd: Syntax error on line 150 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/libphp.so into server: ld.so.1: httpd: fatal: relocation error: file /usr/local/apache2/modules/libphp.so: symbol EVP_md2: referenced symbol not found

Do you know what module EVP_md2 is taken from?

[charlie333333]

I can see this...

/usr/local/ssl/lib
garnet(205) $ strings libcrypto.so.1.0.0 | grep md2
md2WithRSAEncryption

/usr/local/ssl/lib
garnet(222) $ strings libcrypto.so.1.0.0 | grep EVP
EVP part of OpenSSL 1.0.1j 15 Oct 2014

/usr/lib
garnet(207) $ strings libcrypto.so.1.0.0 | grep md2
md2WithRSAEncryption
md2(char)
md2(int)

/usr/lib
garnet(220) $ strings libcrypto.so.1.0.0 | grep EVP
EVP part of OpenSSL 1.0.2zi  1 Aug 2023