| Summary: | =dev-lang/php-7.0.15: incorrect dependency on sys-libs/dev-db | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Room Cays <roomcays> |
| Component: | Current packages | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I think what happened is that your PHP was built against db-4.8, and then you upgraded to db-5.3, removing db-4.8 in the process.
The dependency in php-*.ebuild doesn't catch that:
berkdb? ( || ( sys-libs/db:5.3
sys-libs/db:5.1
sys-libs/db:4.8
sys-libs/db:4.7
sys-libs/db:4.6
sys-libs/db:4.5 ) )
It's not obvious how to get PHP to bind to the right slot... probably some slot-operator dependency trick.
Michael, I thought the same at the first moment. But wouldn't rebuilding PHP7 without sys-libs/db:4.8 available (installed) solve the issue? I've tried that without success. (In reply to Room Cays from comment #2) > Michael, I thought the same at the first moment. > But wouldn't rebuilding PHP7 without sys-libs/db:4.8 available (installed) > solve the issue? Yeah, it should have. > I've tried that without success. :( Let's rule out the easy things first: can you check that /usr/bin/php points where you think it does, and that /usr/bin/php is what gets executed when you run "php"? If those both check out, then can you track down the build log for the version of PHP that's crashing? If both db-5.3 and 4.8 are installed, the config.m4 file for the "dba" extension is supposed to prefer 5.3, and something to that effect should be output during ./configure. Strange thing happened.
To re-compile PHP7 and check output of ./configure I have uninstalled sys-libs/db:4.8 and... PHP7 still works properly!
Then I started thinking (!) and... I am ashamed. It appeared that when calling
$ php7
I was calling /opt/php7/bin/php via system-wide symlink I have created to access PHP 7 instance I have installed some time ago directly from PHP sources. Making this instance obsolete makes "php7" unavailable and "php7.0" executable point to "/usr/bin/php7.0" which is correct.
I'm sorry and thank you very much for your time and help, Michael.
Your suggestion:
> can you check that /usr/bin/php points where you think it does, and that /usr/bin/php is what gets executed when you run "php"?
made me realize where the problem lied.
Thank you once again!
(In reply to Room Cays from comment #4) > > I was calling /opt/php7/bin/php > > ... > > Thank you once again! No problem, I've done the same thing a million times. I'm glad there's nothing to fix =) |
In my current server configuration I do have installed sys-libs/db:5.3 and dev-lang/php in two slots: 5.6 and 7.0. PHP 7.0 compiles successfully but trying to execute the interpreter from CLI gives an error: php7: error while loading shared libraries: libdb-4.8.so: cannot open shared object file: No such file or directory Recompilation of PHP7 with only sys-libs/db:5.3 installed didn't help. Installing sys-libs/db:4.8 manually solves the problem.