Bugzilla Bug 71305

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