Bug 74643 - ndbm.h isn't present in /usr/include
ndbm.h isn't present in /usr/include
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gdbm (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-28 14:30 EDT by Richard Lloyd
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-10 10:17:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Lloyd 2002-09-28 14:30:03 EDT
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.
Comment 1 Daniel Roesen 2004-01-28 19:37:24 EST
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....
Comment 2 Jeff Johnson 2004-10-10 10:17:54 EDT
There is no way to satisy multiple ndbm emulations in various
db packages with a single symlink.
Comment 3 Richard Lloyd 2004-10-10 11:00:17 EDT
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?
Comment 4 Jeff Johnson 2004-10-11 10:35:05 EDT
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.
Comment 5 Richard Lloyd 2004-10-11 11:32:13 EDT
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?
Comment 6 Richard Lloyd 2004-10-11 11:34:05 EDT
Oops, I meant #include <gdbm/ndbm.h> in that last sentence on my most
recent comment...
Comment 7 Jeff Johnson 2004-10-11 11:56:18 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.