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!
Differential D26848
PHP 8.0 RC 2 tz on Oct 19 2020, 12:11 AM. Authored by Tags None Referenced Files
Details
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
Event TimelineComment Actions xmlrpc is also gone as an extension, right? Comment Actions 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. Comment Actions I executed: poudriere testport -p gitlab -j 121amd64 lang/php80-extensions But I got some errors: I enabled some more ports in php80-extensions (the normal settings I use for all php versions). Comment Actions 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 ;) Comment Actions 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. Comment Actions 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. Comment Actions
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. Comment Actions 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? Comment Actions Dear Torsten, thanks a lot for this new version and that it is already committed. I migrated now all my deployment to not have ZTS enabled anymore. Comment Actions @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 Comment Actions 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. |