Project

Profile

Help

Feature #4842

closed

PHP 8

Added by Peter Jan about 2 years ago. Updated 17 days ago.

Status:
Closed
Priority:
High
Category:
PHP Build
Start date:
2020-11-26
Due date:
% Done:

100%

Estimated time:
Found in version:
11.4
Fixed in version:
12.0
Platforms:

Description

PHP 8 has been released today, so inevitably someone has to create a ticket and ask if it becomes supported ;)

Is support for PHP8 planned for the next release?


Files

saxonc-make-test-output.txt (37.8 KB) saxonc-make-test-output.txt Output of make test in Saxon.C.API directory Jonathan Turkanis, 2022-11-16 23:58
PHP8_with_arginfo.zip (41.4 KB) PHP8_with_arginfo.zip O'Neil Delpratt, 2022-11-17 17:36

Related issues

Related to SaxonC - Bug #5241: PHP API for Saxon/C HE for PHP version 8.DuplicateO'Neil Delpratt2022-01-26

Actions
Has duplicate SaxonC - Bug #5764: compiling PHP extension failsDuplicateO'Neil Delpratt2022-12-14

Actions
Actions #1

Updated by Peter Jan about 2 years ago

Apologies; should be a feature request and not a bug report.

Actions #2

Updated by Michael Kay about 2 years ago

Perhaps you could be the first to try it and tell us if it already works?

With most platforms (Java, C#, etc) we don't explicitly test or support the product when a new version of the platform comes out, we just rely on the user community to tell us if there's a problem. Usually there isn't.

Actions #3

Updated by Peter Jan about 2 years ago

Ah! In that case, unfortunately it doesn't work. Because the final version is not yet available as a docker image, I tested it on php:8.0.0RC5-fpm. It was working on php:7.4.12-fpm.

Please find the full log here: https://pastebin.com/m3rHAsrL.

To reproduce, run the following Dockerfile:

FROM php:8.0.0RC5-fpm AS php

RUN set -eux; \
    apt-get update && apt-get install -y --no-install-recommends \
        unzip \
    ; \
    rm -rf /var/lib/apt/lists/*;

ARG saxon='libsaxon-HEC-setup64-v1.2.1'
RUN set -eux; \
    cd /tmp && curl -s -o ${saxon}.zip https://www.saxonica.com/saxon-c/${saxon}.zip; \
    unzip ${saxon}.zip; \
    ./${saxon} -batch -dest /tmp/saxon; \
    cp /tmp/saxon/libsaxonhec.so /usr/lib/; \
    cp -r /tmp/saxon/rt /usr/lib; \
    ldconfig; \
    cd /tmp/saxon/Saxon.C.API/; \
    sed -i 's/#define PHP_SAXON_EXTNAME  "Saxon\/C"/#define PHP_SAXON_EXTNAME  "SaxonC"/g' php_saxon.h; \
    phpize; \
    ./configure --enable-saxon; \
    make -j$(nproc); \
    make install; \
    docker-php-ext-enable saxon; \
    rm -rf /tmp/${saxon}.zip /tmp/${saxon} /tmp/saxon;
Actions #4

Updated by O'Neil Delpratt about 2 years ago

  • Tracker changed from Bug to Feature

Thanks for looking into this. I am not surprised it does not work. We will have investigate what changes need to be made to migrate our extension from PHP7 to PHP8.

Aside from PHP7 and PHP8 support, I am now wondering if we still need to support PHP5.

Actions #5

Updated by Peter Jan about 2 years ago

Well considering that PHP 5 went EOL almost 2 years ago :) I'm not sure if that would mean improvements can be made which were previously not possible because you had to support both versions? I'm not an extension developer so I really couldn't tell.

https://www.php.net/supported-versions.php

The build problems reported above look really similar to the issues reported here: https://github.com/docker-library/php/issues/571

But maybe you already know :)

Actions #6

Updated by Peter Jan almost 2 years ago

I noticed in another issue you're mentioning Saxon/C 1.3; Is PHP 8 support planned for 1.3 as well? I'm asking because this extension is currently my last blocker for using PHP 8 and I would very much like to upgrade.

I found the PR's below where another extension is upgraded to PHP 8, maybe they're of use :).

https://github.com/php-decimal/ext-decimal/pull/53 https://github.com/php-decimal/ext-decimal/pull/54

Actions #7

Updated by O'Neil Delpratt almost 2 years ago

  • Category set to PHP Build
  • Assignee set to O'Neil Delpratt
  • Priority changed from Low to Normal

Hi thanks for the reminder on this issue. Saxon/C 1.3 development is coming alone well, hopefully I can start looking at the PHP 8 support by the end of this week.

Actions #8

Updated by Peter Jan almost 2 years ago

Awesome. Thank you!

Actions #9

Updated by Rein Baarsma over 1 year ago

Any update? We'd like to update to PHP 8.0 and later this year to PHP 8.1

PHP 7.4 active support is ending in november..

Actions #10

Updated by O'Neil Delpratt over 1 year ago

Hi, sorry I have not investigated this as yet. It is still on our to do list.

Actions #11

Updated by Alan Bachelin about 1 year ago

Hi, have you been able to make progress on the update for compatibility with php 8? thanks in advance

Actions #12

Updated by O'Neil Delpratt about 1 year ago

Hi, It is still on our todo list.

Actions #13

Updated by O'Neil Delpratt about 1 year ago

  • Priority changed from Normal to High

PHP 8 did not make it in the SaxonC 11 release. But we hope to work on it for the next maintenance release of SaxonC.

Actions #14

Updated by O'Neil Delpratt 11 months ago

  • Related to Bug #5241: PHP API for Saxon/C HE for PHP version 8. added
Actions #15

Updated by Peter Jan 6 months ago

Any news? :)

Actions #16

Updated by Jonathan Turkanis 4 months ago

HI,

My company has been using the Saxon/C PHP API since 2016 and has come to depend on it in several of our production systems. We are currently upgrading our PHP system to use PHP 8.1 instead of 7.x, which will reach EOL on Nov 28 (PHP 8.0 will also be EOL around the same date: https://endoflife.software/programming-languages/server-side-scripting/php). Therefore I was shocked, last week, to learn that Saxon/C does not support PHP 8.1 and apparently has not made preparations to continue to support PHP before all the PHP platforms it currently supports become obsolete.

Because we can't continue to run PHP 7.x on public web servers after its EOL date, we have decided to quickly rewrite our publicly accessible code to remove the use of XSL 2.0 and above. Because of the inadequacy of XSL 1.0, this means we are switching to an entirely different (and less flexible) templating system. We also have some internal systems that make more extensive use of XSL and probably can't be feasibly rewritten to use some other system. Because they are not directly accessible to the public, we can justify keeping them running on PHP 7.4 for a limited period of time, but not for long. Because it's probably not feasible to eliminate the use of XSL, we will soon have to discontinue one of our products if Saxon/C does not provide PHP 8 soon.

Are you planning to support PHP 8 anytime in the near future? If not, it wold be a real shame, because it will leave the PHP community without support for modern XML, as you argue here (https://news-web.php.net/php.internals/100811). I don't know how large your current user base is, but it seems to me that many companies, after having rewritten theirs systems to eliminate Saxon/C, will not find it practical to start using it again in the future if it becomes available again.

At this point, even posting a patch, instead of release an update, would be very helpful.

Actions #17

Updated by Michael Kay 4 months ago

Every project needs to make its own policies on keeping up with technology changes, so I can't dispute your reasoning. However, our biggest concern in this area is not the withdrawal of formal support for PHP 7, but the complete absence of support for Excelsior Jet, on which SaxonC depends. We have therefore been working hard to re-engineer SaxonC to remove this dependency. Producing a patch update of SaxonC that supports PHP 8, while still depending on Excelsior JET, would achieve little for users who want all the software in their stack to be fully supported (although it would be useful, of course, for users who want PHP 8 for other reasons). But our top priority is getting rid of the Excelsior dependency. We've made very good progress on that, and are now working on retro-fitting the PHP and Python front ends, but we are still a couple of months away from a release.

Actions #18

Updated by O'Neil Delpratt 4 months ago

Just to add to comment #17. It is our priority to support PHP 8 in the upcoming SaxonC 12 release. We are almost there with the underlying C++ API and the python extension. And next is the PHP extension. We never like to set deadlines, but I would say we are 1-2 months away from a release.

Actions #19

Updated by O'Neil Delpratt 3 months ago

  • Status changed from New to In Progress

Reporting some progress made with SaxonC and PHP8.

I have managed make the necessary changes to SaxonC 12.1. It now compiles and installed on my PHP 8.1 server.

Actions #20

Updated by Jonathan Turkanis 3 months ago

Thanks for the update!

Actions #21

Updated by O'Neil Delpratt 3 months ago

  • File PHP8.zip added

SaxonC 12 will support PHP 8, but we would like to patch SaxonC 11 with the fix in the next maintenance release.

I have attached a zip of all the files for the PHP8 patch to this bug issue. These contain the files that need copying across to the Saxon.C.API directory. Notice here we replace the config.m4 file.

For this PHP8 patch, the XSLT user-defined extension for PHP does not work. I am still investigating a solution for this, but it should affect you.

Please test it and let me know how it goes.

Actions #22

Updated by Jonathan Turkanis 3 months ago

After installing the files in PHP8.zip, "phpize" and "make" complete successfully, but "make test" fails as follows (see attached file for the complete output):

Build complete.
Don't forget to run 'make test'.


=====================================================================
PHP         : /usr/bin/php 
Warning: Missing arginfo for Saxon\SaxonProcessor::__construct() in Unknown on line 0

Warning: Missing arginfo for Saxon\SaxonProcessor::__destruct() in Unknown on line 0

Warning: Missing arginfo for Saxon\SaxonProcessor::createAtomicValue() in Unknown on line 0
...
...
...
--------------------------------------------------------------------- 
CWD         : /home/jonathant/saxon/libsaxon-HEC-11.4/Saxon.C.API
Extra dirs  : 
VALGRIND    : Not used
=====================================================================
TIME START 2022-11-16 22:52:35
=====================================================================
No tests were run.

I get similar warnings if I install the library and run the PHP CLI.

P.S. Sorry I didn't reply sooner; I hadn't watched this ticket.

Actions #23

Updated by O'Neil Delpratt 2 months ago

Thanks for your reply. Did your scripts work in PHP8?

I have a further update to solve the arginfo warnings which I have applied to the next release. I will create another zip file for SaxonC 11 shortly.

Actions #24

Updated by O'Neil Delpratt 2 months ago

Please find attached updated PHP8 files with the arginfo information.

Again please test it and let me know how it goes.

Thanks.

Actions #25

Updated by O'Neil Delpratt 2 months ago

  • Status changed from In Progress to AwaitingInfo
Actions #26

Updated by Martin Honnen 2 months ago

Hi O'Neil,

I checked my WSL/Linux installations for the PHP version, it seems Ubuntu 22 now comes with PHP 8.1 as the default. Is that PHP8_with_arginfo.zip worth a try with PHP 8.1 or is it only for 8.0?

Actions #27

Updated by O'Neil Delpratt 2 months ago

PHP 8.1 is a minor release, so I think it should work. maybe give it a try and let us know.

Actions #28

Updated by Martin Honnen 2 months ago

I have tried it on one system trying to make sense of the instructions https://www.saxonica.com/saxon-c/documentation11/index.html#!starting/installingphp in terms of PHP 8.1, I guess the nano /etc/php/7.X/mods-available/20-saxon.ini would be nano /etc/php/8.1/mods-available/20-saxon.ini, to "update" it in terms of the version.

Is that name 20-saxon.ini right, that directory for the rest of the existing extensions has simple ini files. Or will the phpenmod saxon create the saxon.ini from that 20-saxon.ini?

So far I couldn't get it to work (php --info doesn't show the Saxon module, only some confusing failed loading attempts of an .so and/or .so.so in some PHP dir with a date in the path) and I am not sure which part of my installation steps failed. I will check back tomorrow to give the exact details, I am currently not at the system with the Ubuntu 22/PHP 8.1 where I tried it.

Actions #29

Updated by Martin Honnen 2 months ago

The attempt with

nano /etc/php/8.1/mods-available/20-saxon.ini



phpenmod saxon

just leads to a warning that no saxon.ini was found. So I simply copied that 20-saxon.ini as saxon.ini in that /etc/php/8.1/mods-available directory. That seems to make the saxonc available in php --info and also allow using the module in PHP 8.1 command line script.

make test doesn't show any warning but says "No tests were run.". No idea whether that is due to the pure command line version of PHP 8.1 installed by default for Ubuntu WSL or is not supposed to show anything more.

Actions #30

Updated by Jonathan Turkanis 2 months ago

O'Neil,

I was not able to test the initial version with the arginfo warnings because our code is very sensitive to warnings and so wouldn't run.

WIth the arginfo update, the extension builds and loads without warnings, and I am able to construct processor objects successfully. However, I am unable to run our units test for saxon because of apparent interface changes:

  1. Previously we used Saxon\XsltProcessor; I updated this to Saxon\Xslt30Processor everywhere
  2. Previously, we would call getExceptionCount() to check for errors, and then call getErrorCode() and getErrorMessage() with integer indices; I has replaced this with exceptionOccurred(), and now call getErrorCode() and getErrorMessage() with no arguments.
  3. Previously, we would call compileFromFile(), setSourceFromFile(), and then TransformToString(). It appears that the last 2 methods no longer exist, and I can't figure out what to replace them with.

How should I update my code?

Actions #31

Updated by O'Neil Delpratt 2 months ago

Jonathan Turkanis wrote in #note-30:

  1. Previously we used Saxon\XsltProcessor; I updated this to Saxon\Xslt30Processor everywhere
  2. Previously, we would call getExceptionCount() to check for errors, and then call getErrorCode() and getErrorMessage() with integer indices; I has replaced this with exceptionOccurred(), and now call getErrorCode() and getErrorMessage() with no arguments.
  3. Previously, we would call compileFromFile(), setSourceFromFile(), and then TransformToString(). It appears that the last 2 methods no longer exist, and I can't figure out what to replace them with.

How should I update my code?

There are two main ways you can go about it:

  1. The Saxon\Xslt30Processor class has a few one short transform methods which should work in the same way with minimum change to your code. For example:
 transformFileToString(string $sourceFileName, string $stylesheetFileName)

(See: https://www.saxonica.com/saxon-c/documentation11/index.html#!api/saxon_c_php_api/saxon_c_php_xslt30processor)

  1. If your PHP scripts requires the reusing of the compiled stylesheet then I would recommend compiling the stylesheet using one of the compile methods in the @Saxon\Xslt30Processor@ class which creates a @Saxon\Executable@ object where you can use to execute the compiled stylesheet. Here you set the source document using either @setInitialMatchSelection@ or @setInitialMatchSelectionAsFile@. For XSLT 3.0 stylesheets you may need to set the global context too.

See: https://www.saxonica.com/saxon-c/documentation11/index.html#!api/saxon_c_php_api/saxon_c_php_xsltexecutable

There are several sample scripts in the directory samples/php. Specifically look at the xslt30Example.php script.

Actions #32

Updated by Jonathan Turkanis 2 months ago

This morning I finished rewriting our code to use the version 11 interface and was able to get all of our unit and functional tests to pass.

I am going to release our code now using the patch you posted here. Thanks for all your help!

Do you have an update on when the release will be available?

Actions #33

Updated by O'Neil Delpratt about 2 months ago

We are in the final stages of testing. However Christmas might come too soon. Let see.

Actions #34

Updated by O'Neil Delpratt about 2 months ago

  • Has duplicate Bug #5764: compiling PHP extension fails added
Actions #35

Updated by O'Neil Delpratt about 2 months ago

  • File deleted (PHP8.zip)
Actions #36

Updated by O'Neil Delpratt about 2 months ago

  • Status changed from AwaitingInfo to Resolved
  • Found in version set to 11.4
Actions #37

Updated by O'Neil Delpratt 17 days ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 12.0

Bug fix applied in the SaxonC 12.0 major release.

Please register to edit this issue

Also available in: Atom PDF