[BlueOnyx:22748] Re: PHP-7.3 issues

[Michael Stauber]

Hi Lars,

> But is it just me, or is 7.3.2 missing Class ZipArchive?

Yes, for now Zip-Support has been removed from PHP-7.3 as I cannot get
it to build with that:

[root at 5209r php-7.3.2]# ./configure --enable-zip [...]
[...]
checking for libzip... configure: error: system libzip must be upgraded
to version >= 0.11

This is the version of libzip we have on CentOS 7 and that library is
supplied by the OS:

[root at 5209r php-7.3.2]# rpm -q libzip
libzip-0.10.1-8.el7.x86_64

Let's see what libraries it provides:

[root at 5209r php-7.3.2]# rpm -ql libzip|grep .so
/usr/lib64/libzip.so.2
/usr/lib64/libzip.so.2.1.0

That's what PHP and everything that's compiled with Zip functionality
wants to link or compile against. To simplify the explanation I'll say
this: We cann only seamlessly upgrade "libzip" if the library names and
extensions stay the same.

I checked what other RPM and SRPM sources have available as drop in
replacements in regards to a newer "libzip":

Epel: 			Nothing
Remi:			libzip-last-1.1.3-1.el7.remi.x86_64.rpm
Remi:			libzip5-1.5.1-1.el7.remi.x86_64.rpm
Psychotic Ninja Plus:	libzip-0.11.2-6.el7.psychotic.x86_64.rpm
Fedora Core 28/29:	libzip-1.5.1-2.fc29.x86_64.rpm

Recompiling the SRPM for FC28 or FC29 would break CentOS 7, as too many
other RPMs expect to find libzip.so.2, but that RPM would then replace
our libzip.so.2 libzip.so.5.

Remi's "libzip-last" (brings libzip.so.4)  and "libzip5" (brings
libzip.so.5) would work, as they don't replace the onboard "libzip", but
install side by side.

The RPM from "Psychotic Ninja Plus" (doesn't sound like a reliable
source, right?" brings a "libzip.so.2" that's barely new enough for
PHP-7.3 yet old enough to not change the library's name. It might work,
but I'm not entirely happy with supplying RPMs built from sources of
unknown reputation.

For the next build of PHP-7.3 I'll be looking into ways how we can
upgrade "libzip" without breaking anything. I'll perhaps use the
"libzip5" from Remi as that sounds the most promising.

Another option would be to statically build PHP-7.3 against a newer
"libzip" version that I install on the sidelines on the build-box. In
which case I wouldn't need to ship an updated "libzip" RPM, as the
resulting PHP-7.3 would have it integrated at the price of a bigger
package. However, such static builds also mean that if there is ever a
security flaw found in that version of "libzip", then the whole PHP
package needs to be replaced with one that was built against a fixed
"libzip". Hence I try to avoid static builds for easier long term
maintainability.

-- 
With best regards

Michael Stauber