Bug 74643
Summary: | ndbm.h isn't present in /usr/include | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Lloyd <rkl> |
Component: | gdbm | Assignee: | Jeff Johnson <jbj> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | dr |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-10 14:17:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Richard Lloyd
2002-09-28 18:30:03 UTC
Confirmed... PHP 4.3.4 (not the Red Hat RPM) build breaks because of this symlink missing! Since this problem is still there in FC1, changing product and version number.... There is no way to satisy multiple ndbm emulations in various db packages with a single symlink. I'm a little surprised at Jeff's comment today because of the lack of details. Which db packages (other than gdbm of course) contain ndbm emulations which have their own ndbm.h and hence would cause an include clash? If Red Hat have decided that /usr/include shouldn't contain ndbm.h, then that's fair enough, but it's a shame that the "man gdbm" documentation will therefore remain incorrect when it states that <ndbm.h> is all that's needed to include that header file. Surely changing that to <gdbm/ndbm.h> can't be all that hard, especially if there are indeed multiple ndbm.h implementations? Basically, all databases similar to gdbm have a ndbm.h, and offer a NDBM emulation. Since it is unclear which ndbm.h should go as *THE* ndbm.h because each application has different needs, there can be no single /usr/include/ndbm.h, What is there instead is the ndbm.h for each database. E.g. here is the include file for the gdbm NDBM emulation: $ rpm -ql gdbm-devel | grep ndbm.h /usr/include/gdbm/ndbm.h So add -I/usr/include/gdbm if you wish to use the gdbm NDBM emulation. Since this is now marked as an FC2 issue, I thought I'd do a bit of research to answer my own question - namely, which RPM packages shipped on the FC2 DVD have an ndbm.h file present? With a bit of scripting to loop around with an "rpm -qlp", I discovered just one, predictably, namely: gdbm-devel-1.8.0-22.1.i386.rpm Hence, FC2, unlike some of the Red Hat releases (which used to have db1-devel and/or gnome-libs-devel containing ndbm.h), only ships one ndbm.h, namely /usr/include/gdbm/ndbm.h. So there is still a case for soft-linking ndbm.h in the same manner that gdbm.h is linked. To make things worse, I discovered that the "man-pages" RPM contains an ndbm.h man page, which is also wrong on this issue ("man ndbm.h" just says #include <ndbm.h> to include the file). If the decision is still not to soft-link ndbm.h, then can we please fix the two man pages ("man gdbm" and "man ndbm.h") to say #include <gdbm.h> or that -I/usr/include/gdbm should be used when compiling? Oops, I meant #include <gdbm/ndbm.h> in that last sentence on my most recent comment... Even though there may only be a single occurence of ndbm.h in FC2 does not mean that there aren't other NDBM emulations around, possibly packaged outside of FC2. Adding the symlin to FC2 packages also prevents end-user choice, where ln -s gdbm/ndbm.h /usr/include/ndbm.h might be a reasonable choice, or perhaps some other NDBM emulation. Whether -I/usr/include/gdbm is added to compile flags, or #include <gdbm/ndbm.h> is done is up to individual developers taste and style. |