Summary: | [php extensions] Order of extensions.ini can break modules dependencies | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Renato Botelho <garga> |
Component: | Individual Port(s) | Assignee: | Alex Dupre <ale> |
Status: | Closed Works As Intended | ||
Severity: | Affects Some People | CC: | abriel, franco, ohauer, pi, sebastian |
Priority: | Normal | Keywords: | needs-patch |
Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(ale) |
Hardware: | Any | ||
OS: | Any |
Description
Renato Botelho
2015-10-13 12:04:15 UTC
I found this: https://people.freebsd.org/~ohauer/scripts/fixphpextorder.sh 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. Hi, 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. Best regards Sebastian Hi, 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 Abriel *** 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: Author: mat Date: Tue Aug 9 14:29:15 UTC 2016 New revision: 419924 URL: https://svnweb.freebsd.org/changeset/ports/419924 Log: 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. PR: 203741 Sponsored by: Absolight Changes: head/converters/pecl-igbinary/Makefile head/devel/pecl-msgpack/Makefile head/lang/php55/Makefile.ext head/lang/php56/Makefile.ext head/lang/php70/Makefile.ext head/net/php55-soap/Makefile head/net/php56-soap/Makefile head/net/php70-soap/Makefile head/security/php-suhosin/Makefile head/textproc/php55-pspell/Makefile head/textproc/php56-pspell/Makefile head/textproc/php70-pspell/Makefile head/www/php55-session/Makefile head/www/php56-session/Makefile head/www/php70-session/Makefile 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 |