When one PHP extension depends of another, the order they are loaded in extensions.ini matters and can break it. It's easy to reproduce:
security/php-suhosin depends of www/php56-session, then recently php56 was updated to 5.6.14 but suhosin was not. Then php56-session was updated on the system and it was added to the end of /usr/local/etc/php/extensions.ini.
PHP ended up trying to load suhosin.so before session.so and it ended up with a message like:
Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20131226/suhosin.so' - /usr/local/lib/php/20131226/suhosin.so: Undefined symbol "ps_globals" in Unknown on line 0
After re-order extensions.ini, manually or simply reinstalling php-suhosin, everything worked fine.
I found this:
Maybe some of it could be adapted/adopted in the port.
Renato, do you have any suggestions on resolving this permanently? If so, please include details and/or references
I didn't think too much about it yet. First idea that came to mind was to save a list of dependencies at install time, since we have it on USES_PHP variable. Maybe something like:
suhosin.depend file containing session inside it
Then we could end up with an algorithm to process all depend files and create extensions.ini in the correct order
Been thinking about this too, I was going to embed session into php56, that whole plugin depending on other plugins is too fragile and may lead to overengineering.
(In reply to Franco Fichtner from comment #3)
Adding session embedded into php56 would fix this specific issue, but we need to think on a way to cover all dependency possibilities on the ports tree
Yup, this requires tracking dependencies for PHP plugins as well as extending the write logic for extensions.ini to honour dependencies.
Oh my goodness, I long forgot about the script but would give a statement about it.
Years ago I was running into the same issue and after researching a weekend about all possible known load order issues, collecting working samples and trying mod_php with all modules the portstree knows about this script was hacked.
Even with an clever algo. in the php tree such issues can happen, thing about a user has already 10 modules installed, installs additional software which requires for example additional database module the php installer has to rewrite the whole extension.ini ...
Doing dependency tracking for a flat file only loader introduced by PHP itself. Sounds like the easiest way to fix this is to improve the PHP loader with a little algorithm that will do opportunistic loads and retry until either all modules are loaded or a full remaining modules run won't load. It's not rocket science, PHP knows when loading fails and can do something about it, we don't.
I can confirm the same sort of problem. I just upgraded to PHP 5.6.17 and I am getting the following error message:
Error: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20131226/redis.so' - /usr/local/lib/php/20131226/redis.so: Undefined symbol "php_session_create_id" in Unknown on line 0
The problem is caused by session.so not being loaded before redis.so in extensions.ini. Once I changed the order, things are working fine again.
I had the same problem. In my case:
extension=smbclient.so before extension=ldap.so
breaks php-curl ssl connection with error:
error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac
*** This bug has been marked as a duplicate of bug 210697 ***
Ah, I was not aware of this one, reopen it so that I can have a look at the order of stuff now, and make sure the cases here are taken care of
So, the session extension is fixed.
smbclient will always be loaded after ldap because, well, s is after l, so this is ok too.
A commit references this bug:
Date: Tue Aug 9 14:29:15 UTC 2016
New revision: 419924
Change www/php*-session's priority to be loaded before most other PHP extensions.
Many PHP extensions were adding a build dependency on session, so that
it was loaded first. This is now no longer needed, we have a nice
framework handle the extensions ordering.
Sponsored by: Absolight
Still a problem:
On php73, btw. At least it's consistent 8-}
Is it still a problem? It's a long time I don't have any problems with that
I don't see this problem happening in years and do not see more people complaining about it. We can re-open if we have more information