logo
Apache Lounge
Webmasters

 

About Forum Index Downloads Search Register Log in RSS X


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

A donation makes a contribution towards the costs, the time and effort that's going in this site and building.

Thank You! Steffen

Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
Post new topic   Forum Index -> Building & Member Downloads View previous topic :: View next topic
Reply to topic   Topic: PHP 8.3.3 RC1, 8.2.16 RC1 available Page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Author
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Mon 17 Jun '19 21:19    Post subject: Reply with quote

jfcherng wrote:
It looks like the latest official PHP 7.4 snapshot is still built with 14.20 while ours is built with 14.21. Thus they cannot share extensions.

Code:
Warning: PHP Startup: Can't load module 'ext\php_ast.dll' as it's linked with 14.21, but the core is linked with 14.20 in Unknown on line 0

Try the new x64 nts build now.

https://phpdev.toolsforresearch.com/php-7.4.0alpha1-nts-Win32-vs16-x64.htm
https://phpdev.toolsforresearch.com/php-7.4.0alpha1-nts-Win32-vs16-x64.zip

The Visual Studio Installer had an option to download the 14.20 toolset. By putting those tools earlier in the path, I could compile with Microsoft (R) Program Maintenance Utility Version 14.20.27508.1.

Code:
N:\php-sdk\php74dev>where link
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\HostX64\x64\link.exe
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\Hostx64\x64\link.exe
C:\cygwin\bin\link.exe
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Tue 18 Jun '19 1:48    Post subject: Reply with quote

I downgraded all PHP 7.4 builds to the 14.20 toolset. And while doing that confirmed that 14.20 extensions load fine in a 14.20 or 14.21 PHP. The only thing that does not work is loading 14.21 extensions in a 14.20 PHP.

The php.net build host will be upgraded one of these days to 14.21. That will not change the Alpha1 on https://windows.php.net/qa , but most likely Alpha2 will be 14.21.
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 3049
Location: Hilversum, NL, EU

PostPosted: Tue 18 Jun '19 10:46    Post subject: Reply with quote

See also the discussion at https://developercommunity.visualstudio.com/content/problem/599593/vs-20191-update-removes-142027508-toolset.html
Back to top
jfcherng



Joined: 17 Jun 2019
Posts: 11
Location: Taiwan

PostPosted: Tue 18 Jun '19 14:04    Post subject: Reply with quote

James Blond wrote:
Did you use the last snapshot pecl?

https://windows.php.net/downloads/pecl/snaps/ast/


As the link you provided, the ast (and every) extension has not been built for PHP 7.4 yet.
Back to top
jfcherng



Joined: 17 Jun 2019
Posts: 11
Location: Taiwan

PostPosted: Tue 18 Jun '19 14:21    Post subject: Reply with quote

Jan-E wrote:

Try the new x64 nts build now.

https://phpdev.toolsforresearch.com/php-7.4.0alpha1-nts-Win32-vs16-x64.htm
https://phpdev.toolsforresearch.com/php-7.4.0alpha1-nts-Win32-vs16-x64.zip

The Visual Studio Installer had an option to download the 14.20 toolset. By putting those tools earlier in the path, I could compile with Microsoft (R) Program Maintenance Utility Version 14.20.27508.1.

Code:
N:\php-sdk\php74dev>where link
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\HostX64\x64\link.exe
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\Hostx64\x64\link.exe
C:\cygwin\bin\link.exe


Thanks for providing a new build.

It looks like some of extensions are still built with the old module API (20180731) while PHP 7.4 alpha 1 is using a new one (20190529). In my case, they are "decimal" and "xlswriter".

Code:
Warning: PHP Startup: decimal: Unable to initialize module
Module compiled with module API=20180731
PHP    compiled with module API=20190529
These options need to match
 in Unknown on line 0

Warning: PHP Startup: xlswriter: Unable to initialize module
Module compiled with module API=20180731
PHP    compiled with module API=20190529
These options need to match
 in Unknown on line 0
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Tue 18 Jun '19 16:29    Post subject: Reply with quote

There are no modules decimal and xlswriter in my 7.4 builds...
Back to top
jfcherng



Joined: 17 Jun 2019
Posts: 11
Location: Taiwan

PostPosted: Tue 18 Jun '19 17:01    Post subject: Reply with quote

Jan-E wrote:
There are no modules decimal and xlswriter in my 7.4 builds...


Sorry. Maybe I just messed up my local files. It was my fault.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Wed 19 Jun '19 8:59    Post subject: Reply with quote

Steffen wrote:
See also the discussion at https://developercommunity.visualstudio.com/content/problem/599593/vs-20191-update-removes-142027508-toolset.html

Ouch.

Did you build Apache VS16 with 14.20 or 14.21? And did you check if php7apache2_4.dll loads in Apache (mod_php)?
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 3049
Location: Hilversum, NL, EU

PostPosted: Wed 19 Jun '19 9:27    Post subject: Reply with quote

14.21 and yes


It is only a PHP start up check and is new in PHP 7.4; it has been introduced to ensure that only modules which have been built with a linker version less than or equal to the linker version which has been used to built the core can beloaded, just to prevent eventual issues wrt. dynamic loading. The coming 7.4.0alpha2 should be build at least with 14.21.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Wed 19 Jun '19 9:39    Post subject: Reply with quote

Steffen wrote:
It is only a PHP start up check and is new in PHP 7.4; it has been introduced to ensure that only modules which have been built with a linker version less than or equal to the linker version which has been used to built the core can beloaded, just to prevent eventual issues wrt. dynamic loading. The coming 7.4.0alpha2 should be build at least with 14.21.

I know. I have been mailing with Anatol aka weltling yesterday, because the official 7.4.0 Alpha 1 release candidates of php_wincache.dll had to be rebuilt by Eric Stensen.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Wed 19 Jun '19 10:48    Post subject: Reply with quote

Added a couple more extensions, including the one why I started compiling PHP myself anyway: php_ffmpeg.dll.

php_ffmpeg.dll is used for getting properties of a videofile (width/height/aspect ratio) and making a thumbnail.
Back to top
jimski



Joined: 18 Jan 2014
Posts: 196
Location: USSA

PostPosted: Fri 05 Jul '19 9:30    Post subject: Reply with quote

Jan-E, php_ffmpeg is an excellent idea and a very nice extension. On the next release perhaps you could also include php_redis which is another underappreciated extension. I'm surprised that so few developers use either one of them.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Sun 07 Jul '19 10:47    Post subject: Reply with quote

redis does not compile yet for PHP 7.4:
https://travis-ci.org/phpredis/phpredis/jobs/554772903

Furthermote, in the *nix version it requires the msgpack extension, which also does not compile yet for PHP 7.4.

In all my other builds both are included.
Back to top
jfcherng



Joined: 17 Jun 2019
Posts: 11
Location: Taiwan

PostPosted: Sun 07 Jul '19 19:26    Post subject: Reply with quote

Jan-E wrote:
redis does not compile yet for PHP 7.4:
https://travis-ci.org/phpredis/phpredis/jobs/554772903

Furthermote, in the *nix version it requires the msgpack extension, which also does not compile yet for PHP 7.4.

In all my other builds both are included.



But it looks like the error you indicated is in the list of `Allowed Failures` (and it's not for Windows)?
I have built the latest commit of igbinary/msgpack/redis for PHP 7.4.0-dev NTS x64 successfully on my Windows PC.
I only tested basic set/get functions for redis though...
Built DLLs: https://github.com/jfcherng/php74-exts-test/tree/master/ext

I am using
Code:
configure --disable-zts --disable-all --enable-cli --enable-session --enable-json --enable-zlib --enable-igbinary=shared --with-openssl=shared --enable-redis=shared --enable-redis-igbinary --enable-msgpack=shared
.
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Sun 07 Jul '19 21:02    Post subject: Reply with quote

Did you patch msgpack before compiling the PHP 7.4 version?

It uses uint and ulong, which have been removed in PHP 7.4:

Code:
ext\msgpack\msgpack_convert.c(7): error C2081: 'uint': name in formal parameter list illegal
ext\msgpack\msgpack_convert.c(105): error C2065: 'ulong': undeclared identifier
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Sun 07 Jul '19 21:19    Post subject: Reply with quote

The same account for redis. Just a couple of examples:

N:\php-sdk\php74dev\ext\redis\library.h(31): error C2081: 'ulong': name in formal parameter list illegal (compiling source file ext\redis\redis_cluster.c)

ext\redis\redis_commands.c(575): error C2065: 'ulong': undeclared identifier

ext\redis\redis_commands.c(1332): error C2065: 'ulong': undeclared identifier

N:\php-sdk\php74dev\ext\redis\redis_array.h(72): error C2081: 'uint': name in formal parameter list illegal (compiling source file ext\redis\redis_array_impl.c)
Back to top
jfcherng



Joined: 17 Jun 2019
Posts: 11
Location: Taiwan

PostPosted: Mon 08 Jul '19 5:51    Post subject: Reply with quote

Jan-E wrote:
Did you patch msgpack before compiling the PHP 7.4 version?

It uses uint and ulong, which have been removed in PHP 7.4:

Code:
ext\msgpack\msgpack_convert.c(7): error C2081: 'uint': name in formal parameter list illegal
ext\msgpack\msgpack_convert.c(105): error C2065: 'ulong': undeclared identifier


I add typedefs to the top of the problematic file. (better to add them in a .h file but I just want it to be compile-able at that time)

Code:
typedef unsigned int uint;
typedef unsigned long ulong;


redis is quite the same. Added in common.h and library.h.
vld is added in srm_oparray.c.

Ugly patch though.

I just saw the reference link from a comment you made in external.io. So it should better to be

Code:
#include <stdint.h>
#include "zend_types.h"
typedef uint32_t uint;
typedef zend_ulong ulong;


for my ugly personal patch (without making PRs to the exts' repo).


Last edited by jfcherng on Mon 08 Jul '19 6:31; edited 2 times in total
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Mon 08 Jul '19 6:11    Post subject: Reply with quote

jfcherng wrote:
Jan-E wrote:
Did you patch msgpack before compiling the PHP 7.4 version?

Code:
typedef unsigned int uint;
typedef unsigned long ulong;

Ugly manual patch though.

Ugly indeed. I only apply patches that are proposed as a PR (pull request) to the extension developer. Examples:
https://github.com/php/pecl-web_services-oauth/pull/5
https://github.com/php/pecl-search_engine-solr/pull/14
https://github.com/php/pecl-text-ereg/pull/1
Back to top
jfcherng



Joined: 17 Jun 2019
Posts: 11
Location: Taiwan

PostPosted: Mon 08 Jul '19 6:36    Post subject: Reply with quote

Jan-E wrote:
jfcherng wrote:
Jan-E wrote:
Did you patch msgpack before compiling the PHP 7.4 version?

Code:
typedef unsigned int uint;
typedef unsigned long ulong;

Ugly manual patch though.

Ugly indeed. I only apply patches that are proposed as a PR (pull request) to the extension developer. Examples:
https://github.com/php/pecl-web_services-oauth/pull/5
https://github.com/php/pecl-search_engine-solr/pull/14
https://github.com/php/pecl-text-ereg/pull/1


That makes sense. It's always better having officials' review. Very Happy
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Tue 09 Jul '19 14:47    Post subject: Reply with quote

PHP 7.4.0 Alpha 3 had a BC break, typically for a Alpha release. The ast, taint and xdebug do not compile anymore:

Code:
ext\ast\ast.c(446): error C2065: 'ZEND_ASSIGN_BW_OR': undeclared identifier
ext\ast\ast.c(447): error C2065: 'ZEND_ASSIGN_BW_AND': undeclared identifier
ext\ast\ast.c(448): error C2065: 'ZEND_ASSIGN_BW_XOR': undeclared identifier
ext\ast\ast.c(449): error C2065: 'ZEND_ASSIGN_CONCAT': undeclared identifier
ext\ast\ast.c(450): error C2065: 'ZEND_ASSIGN_ADD': undeclared identifier
ext\ast\ast.c(451): error C2065: 'ZEND_ASSIGN_SUB': undeclared identifier
ext\ast\ast.c(452): error C2065: 'ZEND_ASSIGN_MUL': undeclared identifier
ext\ast\ast.c(453): error C2065: 'ZEND_ASSIGN_DIV': undeclared identifier
ext\ast\ast.c(454): error C2065: 'ZEND_ASSIGN_MOD': undeclared identifier
ext\ast\ast.c(455): error C2065: 'ZEND_ASSIGN_POW': undeclared identifier
ext\ast\ast.c(456): error C2065: 'ZEND_ASSIGN_SL': undeclared identifier
ext\ast\ast.c(457): error C2065: 'ZEND_ASSIGN_SR': undeclared identifier

The change is documented here:
https://github.com/php/php-src/blob/PHP-7.4/UPGRADING.INTERNALS#L217

Looks like a simple fix can be applied;
https://github.com/php/php-src/commit/48ca5a1e176c5301fedd1bc4f661969d6f9a49eb#diff-8095b324074c088b219f0af3b0678cc3L1716
Back to top


Reply to topic   Topic: PHP 8.3.3 RC1, 8.2.16 RC1 available View previous topic :: View next topic
Post new topic   Forum Index -> Building & Member Downloads Page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next