From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 Description of problem: The gdbm-devel package has gdbm.h and ndbm.h amongst its files and "man gdbm" says that they are included via <gdbm.h> and <ndbm.h>. However, ndbm.h is *not* in /usr/include (gdbm.h is, albeit a soft-link to /usr/include/gdbm/gdbm.h). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install the gdbm-devel package 2. Look for the gdbm.h and ndbm.h files in /usr/include - the latter isn't present (former is a soft-link). 3. Despite the man page claiming that <ndbm.h> is good enough, the lack of ndbm.h in /usr/include will cause this to fail. Actual Results: No sign of ndbm.h in /usr/include Expected Results: Commercial UNIX distros and other Linux distros (e.g. SuSE) *do* have ndbm.h in /usr/include. Either Red Hat should too or at least correctly document how to include <ndbm.h> (either with <gdbm/ndbm.h> or with -I/usr/include/gdbm) if RH don't want to put an ndbm.h soft-link in /usr/include. Additional info: I would suggest a soft-link from /usr/include/ndbm.h to /usr/include/gdbm/ndbm.h to fix this problem (this was done for gdbm.h, but bizarrely not done for ndbm.h). This problem is present in Red Hat 7.2 and the beta 3 of Red Hat 8.0 ("null") - it's probably also present in 7.3, but I haven't checked that out.
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.