Bug 203741 - [php extensions] Order of extensions.ini can break modules dependencies
Summary: [php extensions] Order of extensions.ini can break modules dependencies
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Some People
Assignee: Alex Dupre
Keywords: needs-patch
Depends on:
Reported: 2015-10-13 12:04 UTC by Renato Botelho
Modified: 2021-06-14 11:32 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (ale)


Note You need to log in before you can comment on or make changes to this bug.
Description Renato Botelho freebsd_committer 2015-10-13 12:04:15 UTC
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.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2015-10-13 12:46:58 UTC
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
Comment 2 Renato Botelho freebsd_committer 2015-10-13 13:26:47 UTC
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
Comment 3 Franco Fichtner 2015-10-13 13:58:05 UTC
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.
Comment 4 Renato Botelho freebsd_committer 2015-10-13 14:06:37 UTC
(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
Comment 5 Franco Fichtner 2015-10-13 14:10:07 UTC
Yup, this requires tracking dependencies for PHP plugins as well as extending the write logic for extensions.ini to honour dependencies.
Comment 6 Olli Hauer freebsd_committer 2015-12-27 11:21:57 UTC
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 ...
Comment 7 Franco Fichtner 2015-12-29 22:12:04 UTC
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.
Comment 8 sebastian 2016-01-25 22:03:15 UTC

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
Comment 9 abriel 2016-02-25 17:36:42 UTC

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

Comment 10 Renato Botelho freebsd_committer 2016-08-09 12:42:22 UTC

*** This bug has been marked as a duplicate of bug 210697 ***
Comment 11 Mathieu Arnold freebsd_committer 2016-08-09 13:16:11 UTC
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
Comment 12 Mathieu Arnold freebsd_committer 2016-08-09 14:29:33 UTC
So, the session extension is fixed.

smbclient will always be loaded after ldap because, well, s is after l, so this is ok too.
Comment 13 commit-hook freebsd_committer 2016-08-09 14:30:17 UTC
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

  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

Comment 14 Kurt Jaeger freebsd_committer 2019-04-24 16:38:51 UTC
Still a problem:

Comment 15 Kurt Jaeger freebsd_committer 2019-04-24 16:39:52 UTC
On php73, btw. At least it's consistent 8-}
Comment 16 Renato Botelho freebsd_committer 2021-03-30 12:38:46 UTC
Is it still a problem? It's a long time I don't have any problems with that
Comment 17 Renato Botelho freebsd_committer 2021-06-14 11:32:18 UTC
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