Page MenuHomeFreeBSD

PHP 8.0 RC 2
ClosedPublic

Authored by tz on Oct 19 2020, 12:11 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 15, 6:00 AM
Unknown Object (File)
Fri, Mar 15, 6:00 AM
Unknown Object (File)
Fri, Mar 15, 5:56 AM
Unknown Object (File)
Mon, Mar 11, 10:47 AM
Unknown Object (File)
Dec 25 2023, 9:06 PM
Unknown Object (File)
Dec 25 2023, 9:06 PM
Unknown Object (File)
Dec 25 2023, 9:05 PM
Unknown Object (File)
Dec 24 2023, 10:31 AM
Subscribers

Details

Summary

Port PHP 8.0 into the FreeBSD tree. Its a repo-copy of 7.4. The module json is gone, since its now part of the core. The rest is fairly straight forward this time. :)

@ale: Can you please check and approve the Mk/Uses/php.mk part? Thank you!

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

tz requested review of this revision.Oct 19 2020, 12:11 AM

The php.mk part looks good to me.

xmlrpc is also gone as an extension, right?
So no need to install the php7?-xmlrpc port for PHP 7.X

xmlrpc is also gone as an extension, right?
So no need to install the php7?-xmlrpc port for PHP 7.X

You mean php80-xmlrpc? Yes, you are right. I forget to mention this. :D It was moved into PECL. So: json is now core and xmlrpc is gone.

I executed: poudriere testport -p gitlab -j 121amd64 lang/php80-extensions

But I got some errors:
https://pkg.fechner.net/build.html?mastername=121amd64-gitlab&build=2020-10-20_13h53m23s

I enabled some more ports in php80-extensions (the normal settings I use for all php versions).

I executed: poudriere testport -p gitlab -j 121amd64 lang/php80-extensions

But I got some errors:
https://pkg.fechner.net/build.html?mastername=121amd64-gitlab&build=2020-10-20_13h53m23s

I enabled some more ports in php80-extensions (the normal settings I use for all php versions).

Are you sure it's your basic setting? The ports failing because of the ZTS option. And this option is broken since 7.0 or even earlier. Same for DEBUG option. See for example here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245034

So this is expected ;)

In D26848#599504, @tz wrote:

Are you sure it's your basic setting? The ports failing because of the ZTS option. And this option is broken since 7.0 or even earlier. Same for DEBUG option. See for example here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245034

So this is expected ;)

I don't know the status on 7.0 and later, so there may be a new issue I'm not aware of, but in all PHP versions I maintained it was working fine. The reason to use different directories is to avoid mixing extensions with different build options, e.g. if now I want a thread safe php I don't want to use an old extension compiled without thread-safety. Once the PHP port is installed, the correct directory is taken from the php.conf file, but if it's not installed yet there is an heuristic, that perhaps needs some adjustment.

In D26848#599533, @ale wrote:
In D26848#599504, @tz wrote:

Are you sure it's your basic setting? The ports failing because of the ZTS option. And this option is broken since 7.0 or even earlier. Same for DEBUG option. See for example here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245034

So this is expected ;)

I don't know the status on 7.0 and later, so there may be a new issue I'm not aware of, but in all PHP versions I maintained it was working fine. The reason to use different directories is to avoid mixing extensions with different build options, e.g. if now I want a thread safe php I don't want to use an old extension compiled without thread-safety. Once the PHP port is installed, the correct directory is taken from the php.conf file, but if it's not installed yet there is an heuristic, that perhaps needs some adjustment.

The main question is if it is really needed at all. I never saw a use-case for the zts/debug handling. While i can understand the idea you explained, it looks like these cases will only occur when building the code by yourself AND switching such basic options afterward. And i think with pkg becoming the main source of installation this scenarios are even more unlikely. So i personally would try to remove it all, but the last attempt failed badly :D

Or to put it into numbers: since 7.0 released in 2015 i got 4 to 7 complaints about ZTS / Debug not working. This stands up against (ten)thousands of working installations. So i really see no need for it.

This revision was not accepted when it landed; it landed in state Needs Review.Oct 21 2020, 10:59 PM
This revision was automatically updated to reflect the committed changes.

The main question is if it is really needed at all. I never saw a use-case for the zts/debug handling. While i can understand the idea you explained, it looks like these cases will only occur when building the code by yourself AND switching such basic options afterward. And i think with pkg becoming the main source of installation this scenarios are even more unlikely. So i personally would try to remove it all, but the last attempt failed badly :D

I'm not sure what you mean with "I never saw a use-case for zts handling". If you are using a threaded SAPI (like apache mpm worker or event) or calling the libphp from a threaded app you must build everything with thread-safe support. With fastcgi or mpm prefork that's not needed and in fact the default is to not build a thred safe php. But while a TS php can work in single threaded apps, the opposite is not true and the bugs may be subtle to be found. I agree with you that mixing extensions compiled with different options is something that usually happens when you manually build ports (and perhaps you were referring to this with zts handling), but that's exactly the reason to have it. If there are ports that install extensions in the non-zts directory when php is built with zts, then this should trigger an alarm: was the extension really compiled in thread safe mode? If so, why did it install in the wrong dir? The last thing you want is to call a non thread safe library from a threaded app.
Said so, I'm not completely against the removal of different directories, but if you do I'd like you to know exactly what were the original reasons so that you can verify that you are not hiding potential issues with its removal.

Much as I’d enjoy it, pkg is the main but not the only installation mechanism. Preventing those users from shooting themselves in the foot is important—and the users who use ports/portmaster are often those who find anything else “too difficult.” Is there perhaps a way to simplify the maintenance burden? Alex makes a good-sounding argument about separating ZTS builds, but do debug builds really need a separate destination too?

Dear Torsten,

thanks a lot for this new version and that it is already committed.
I spent some time to understand why I had this ZTS option enabled. The reason was (and this is going back many years) that I used php together with apache using mod_php.
Using mod_php is not recommended and as I moved to nginx many years ago you must use php_fpm anyway.
So there is not really a need to have this ZTS option enabled and it is even not recommended because the performance of PHP will suffer. I just for myself forgot to disable the ZTS option in PHP.

I migrated now all my deployment to not have ZTS enabled anymore.
For this I just let poudiere rebuild everything and forced a reinstallation with these commands:
pkg clean -ay
pkg info -qoa | grep php | xargs pkg upgrade -fy
pkg info -qoa | grep pecl | xargs pkg upgrade -fy
service php-fpm restart

@mfechner correct, you had a stale WITH_MPM=event in your env and so the heuristic thought to find extensions dependencies in the zts dir, because of threaded apache mpm.

@adamw mixing debug/non-debug extentions don't create issues afaik, but once you have a working logic for the zts directory it doesn't change much to support also the debug, I'd say it's all or nothing

In D26848#599940, @ale wrote:

The main question is if it is really needed at all. I never saw a use-case for the zts/debug handling. While i can understand the idea you explained, it looks like these cases will only occur when building the code by yourself AND switching such basic options afterward. And i think with pkg becoming the main source of installation this scenarios are even more unlikely. So i personally would try to remove it all, but the last attempt failed badly :D

I'm not sure what you mean with "I never saw a use-case for zts handling". If you are using a threaded SAPI (like apache mpm worker or event) or calling the libphp from a threaded app you must build everything with thread-safe support. With fastcgi or mpm prefork that's not needed and in fact the default is to not build a thred safe php. But while a TS php can work in single threaded apps, the opposite is not true and the bugs may be subtle to be found. I agree with you that mixing extensions compiled with different options is something that usually happens when you manually build ports (and perhaps you were referring to this with zts handling), but that's exactly the reason to have it. If there are ports that install extensions in the non-zts directory when php is built with zts, then this should trigger an alarm: was the extension really compiled in thread safe mode? If so, why did it install in the wrong dir? The last thing you want is to call a non thread safe library from a threaded app.
Said so, I'm not completely against the removal of different directories, but if you do I'd like you to know exactly what were the original reasons so that you can verify that you are not hiding potential issues with its removal.

With "I never saw a use-case for zts handling" i wanted to express, that i never saw a real usage of the special handling of the ZTS option in PHP builds. Complains about the broken ZTS option in PHP are very rare. And not a single one since introducing of PHP 7.0 was about mixing ZTS and "normal" build up.

While i can follow your reasoning - thank you for the detailed explaination! - i came to the same conclusion like you. Its an all or nothing approach for ZTS and DEBUG. But to be fair: either way will take a while since i am currently out of time for nearly anything. Starting a company in this times is quite a enjoyable challange, but also a time killer ;)

Ale, whould you see a need for the special ZTS handling if we would greate a ZTS-Flavor of the PHP build?

@adamw you are right about the other mechanisms, of course! But they are clearly fading out (in my experience) since even the combination of poudriere + pkg gets you better results the ports/portmaster/etc. But back to your question: any help to solve the ZTS issue would be great. It used to work just fine before PHP 7. And i am confident, that a fix will apply to all versions and wont introduce any burden at all.