When I start the Apache 1 webserver, with PHP (and mod_php) eneabled, I was getting an error about the lack of libgpg-error: Syntax error on line 255 of /etc/apache/conf/apache.conf: Cannot load /etc/apache/extramodules/libphp4.so into server: libgpg-error.so.0: cannot open shared object file: No such file or directory [ !! ] This was resolved by installing libgpg-error. However, it would appear this is a dependency that is somehow not properly coded in portage. I assume it is the mod_php ebuild at fault. Reproducible: Always Steps to Reproduce: 1.emerge mod_php and php 2. don't have libgpg-error installed 3. start apach with "-D PHP4" Actual Results: Syntax error on line 255 of /etc/apache/conf/apache.conf: Cannot load /etc/apache/extramodules/libphp4.so into server: libgpg-error.so.0: cannot open shared object file: No such file or directory [ !! ]
PHP does NOT use or depend on libgpg-error in any way. PHP is linked against some library on your system and that library is linked against libgpg-error. When you removed libgpg-error in the past, you did not recompile that other library. this should resolve it: emerge unmerge libgpg-error revdep-rebuild
I did not state that this was a dependency of PHP, rather a dependency of mod_php. I followed your instructions and look see what happened (see below), it wants to re-emerge php and mod_php. This is because the file: /usr/lib/apache/libphp4.so requires libgpg-error. That file belongs to mod_php conf # revdep-rebuild -- -p Checking reverse dependencies... Packages containing binaries and libraries broken by any package update, will be recompiled. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/lib/apache/libphp4.so (requires libgpg-error.so.0 libgpg-error.so.0) broken /usr/lib/apache-extramodules/libphp4.so (requires libgpg-error.so.0 libgpg-error.so.0) broken /usr/lib/python2.3/site-packages/libxsltmod.so (requires libgpg-error.so.0 libgpg-error.so.0) broken /usr/lib/libgcrypt.so.11.1.0 (requires libgpg-error.so.0) broken /usr/lib/libexslt.so.0.8.7 (requires libgpg-error.so.0 libgpg-error.so.0) broken /usr/bin/php (requires libgpg-error.so.0 libgpg-error.so.0 libgpg-error.so.0) broken /usr/bin/xsltproc (requires libgpg-error.so.0 libgpg-error.so.0 libgpg-error.so.0) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) All prepared. Starting rebuild... emerge --oneshot --nodeps -p =dev-libs/libgcrypt-1.1.94 =dev-libs/libxslt-1.1.9-r1 =dev-php/mod_php-4.3.9 =dev-php/php-4.3.9 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-libs/libgcrypt-1.1.94 [ebuild R ] dev-libs/libxslt-1.1.9-r1 [ebuild R ] dev-php/mod_php-4.3.9 [ebuild R ] dev-php/php-4.3.9 Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild. root@newcoremail conf #
Tracking this down a little more it appears that the following happened: On the box that I use to create binary packages, somthing caused libgcrypt to be required. This in turn required libgpg-error to be installed. Apparently mod_php recognized it's existence and linked against it. On the other boxes, when I came to install the binary packages (created on the first box), libgcrypt was pulled in, but NOT libgpg-error. So, it looks like a portage problem, possibly related to improper handling of binary packages.
I'm wondering why so many things on your system there are linked against libgpg-error, as they do NOT use it any way. The only thing in your list there that really uses libgpg-error is libgcrypt. mod_php and PHP use the identical codebase - the mod_php part compiles ~200 extra lines. Thus by saying PHP I mean any of the PHP SAPIs: php-cli, mod_php, php-cgi, etc. PHP uses libxslt (this is in the dependancies), which uses libgcrypt if USE=crypt (which is in the dependancies), and libgcrypt uses libgpg-error (which is in the dependancies). If you unmerge libgpg-error erronously like you did to cause this bug, you will break a lot of things, as you ignored the warning on unmerge.
unless you are using the very latest portage (2.0.51*) you will run into problems with binary packages when USE flags between machines are not the same.
I checked my USE flags -- they are the same on the machines. I does look like some kind of portage problem.
bah, traced it down to libgcrypt have DEPEND on libgpg-error instead of RDEPEND. Passing this bug to the correct person for that...
fixed in 1.2.x
