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.

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 ?

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. :)

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.

Testbuild fine on 11a.

Testbuilds on 12.0a are fine.

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

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.

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

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

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-)

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.