PHP 7.1

[tz]

Summary

The diff brings PHP 7.1 into the ports-tree. It is based on PHP 7.0 and migrates all its modules.

[mat]

It does not show in the review, but make sure all the ports that have previous versions are created using svn cp of the PHP 7.0 ones.

Mk/bsd.default-versions.mk

71

missing comma.

databases/php71-sqlite3/Makefile

1

I have not checked, but you might want to drop all the Created lines from all those ports.

[tz]

Comma added; you found the 2 remaining ale@ references. They are now removed. :)

Currently there is now repo-copy because i developed everything in an git-repo to have clean environment. I will create the repo-copies next week. Should i update the diff again after it?

And does this imply, that i commit all the modules/new ports in a single commit?

[tz]

Attached the changed diff.

[mat]

In D8693#180239, @ports_toco-domains.de wrote:

Currently there is now repo-copy because i developed everything in an git-repo to have clean environment. I will create the repo-copies next week. Should i update the diff again after it?

Sure, I'm just saying, it must be committed as evolutions of php 7.0 and not as new ports.

And does this imply, that i commit all the modules/new ports in a single commit?

How would you commit this if not in one commit ?

[tz]

In D8693#180246, @mat wrote:

In D8693#180239, @ports_toco-domains.de wrote:

Currently there is now repo-copy because i developed everything in an git-repo to have clean environment. I will create the repo-copies next week. Should i update the diff again after it?

Sure, I'm just saying, it must be committed as evolutions of php 7.0 and not as new ports.

Good. :)

And does this imply, that i commit all the modules/new ports in a single commit?

How would you commit this if not in one commit ?

You can commit it port by port and one commit for the framework.
But i want the single commit and the confirmation its a good idea (since i'm new to the team).

So - if you approve this review i'm going to commit it. :)

[mat]

In D8693#180591, @ports_toco-domains.de wrote:

In D8693#180246, @mat wrote:

In D8693#180239, @ports_toco-domains.de wrote:

Currently there is now repo-copy because i developed everything in an git-repo to have clean environment. I will create the repo-copies next week. Should i update the diff again after it?

Sure, I'm just saying, it must be committed as evolutions of php 7.0 and not as new ports.

Good. :)

And does this imply, that i commit all the modules/new ports in a single commit?

How would you commit this if not in one commit ?

You can commit it port by port and one commit for the framework.
But i want the single commit and the confirmation its a good idea (since i'm new to the team).

So - if you approve this review i'm going to commit it. :)

Unless there is a very good reason for doing it as separate commit, always do things as one, atomic, bit.

[pi]

Testbuild fine on 11a.

[pi]

Testbuilds on 12.0a are fine.

[pi]

www/mod_php71 is missing in the patch ? Is there a reason for this ?

[pi]

lang/php71 needs

MODULENAME= libphp7

so that www/mod_php71 builds and installs libphp7 -- otherwise
mod_php71 builds libphp7 and tries to install libphp71 -- which fails.

[pi]

Test-Run of apache24 with mod_php71 fails to start:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 802016000 (LWP 100566/httpd)]
0x000000080d36cb38 in hash_lookup () from /usr/local/lib/libc-client4.so.9

[tz]

This time i added an SVN diff, but it seems not to be applyable. On my test-cluster it ignores the new ports - i have no idea why. :/
Also i added the mod_php71 port, but is currently broken. Since nobody of us seems to use Apache this was an overlook. Please ignore the port in the review, i will fix it later.

[tz]

Mh - also the updated diff is clearly broken and not the diff i uploaded (twice). It misses various changes...

[pi]

I found a solution for the core dump problem.

The php modules are listed in /usr/local/etc/php/ as one-line files.

The problem is the sequence of PHP modules loaded, so there is a very old fix available as:

https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh

So I generated a single extensions.ini file, used the script to create one with the proper order and restarted apache, and it worked 8-)

[pi]

With the comment: Needs some proper way to handle extension loading sequence.

[mat]

In D8693#193477, @pi wrote:

I found a solution for the core dump problem.

The php modules are listed in /usr/local/etc/php/ as one-line files.

The problem is the sequence of PHP modules loaded, so there is a very old fix available as:

https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh

So I generated a single extensions.ini file, used the script to create one with the proper order and restarted apache, and it worked 8-)

The code deciding the order into which the php modules are loaded is very simple, and is documented in php.mk, if there are php modules that are not loaded in the right order, it is very easy to fix, and we do not have to fallback to the mess of the single extensions.ini we had before.

[tz]

Its already committed, so accept it for closing the revision.