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):
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)
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.
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
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
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
$ rpm -ql gdbm-devel | grep 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
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
ln -s gdbm/ndbm.h /usr/include/ndbm.h
might be a reasonable choice, or perhaps some other NDBM emulation.
is added to compile flags, or
is done is up to individual developers taste and style.