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 attachment 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.
Sorry for awakening this thread, but what is the final conclusion then for creating ebuilds for sources that directly include the header files for the c++ bindings (for which there are no symlinks)? I'm trying to make an ebuild and my build fails to locate db_cxx.h: headers.h:10:20: fatal error: db_cxx.h: No such file or directory
This eclass clearly needs a new maintainer (if still needed)
To be honest, I can't remember which ebuild was the one that needed the db bindings (and clearly I was silly enough not to mention it in this thread). I haven't seen this error lately though, so I assume I'm not using this eclass any more. I'm fine with closing this if nobody else objects.
sys-libs/db is its only customer, I would assign this to base-system and change eclass to point them as eclass maintainers, are you ok?
Me, absolutely.
Assigning to base-system since the commit log indicates that they have been taking care of this eclass, and there has been no objection.
