Bugzilla Bug 83940

When I emerge db with C++ support, portage creates symlinks in /usr/include for
db.h and db_185.h but not for cxx_common.h, cxx_except.h and db_cxx.h which are
required to build programs that use C++ interface.

Reproducible: Always
Steps to Reproduce:

Created an attachment (id=52540) [details]
eclass that creates required symlinks

These symlinks are basically there to help broken programs. It's probably
better to use -I/usr/include/db???, also because the actual contents of that
directory do vary and some of the headers have rather generic names.

The problem is that there is no agreement among distros on the location of
header files for Berkeley DB. For example they rside in /usr/include/db4 on
Fedora Core 2 and in /usr/include/db4.x on current gentoo (and FC provides
symlinks in question BTW). What I'm currently trying to do is to make ebuild
for Ice (http://www.zeroc.com) and its build system assumes that bdb's header
files are either accessible on the system's path or live in <bdb_root>/include.
And without those symlinks build fails.

Had I mentioned that this is a feature I dislike in autoconf. It encourages
people to write broken/inflexible configuration scripts. Maybe I need to write
a db autoconf macroset sometime and post it upstream. In any case I'll look
into solving this. It's a bit more complex though as not all versions provide
c++ support (at all, as it is possible to disable it per useflag), and others
have varying headers.

*** Bug 123061 has been marked as a duplicate of this bug. ***

*** Bug 133587 has been marked as a duplicate of this bug. ***

Is it possible to have the symbolic link to db_cxx.h in portage, regardless of
the philosophical ramifications of where the files should reside? It is
inconsistent now.

The reason that there is only a link to the db.h db185.h files is very simple.
These links were added to prevent things from breaking when slotting db. At
least at the time this was done, there were no packages that depended on the
c++ bindings for berkeley db.
Basically, there is little consistency in what the symlinks point to. They are
designed to link to the latest version such that -ldb and and inclusion of
<db.h> are from the same version. Packages should however use specific versions
as supported by those packages. (e.g. by using the db-use eclass) That way the
packages will continue to work in a changing environment.