Bug 2527 - Missing ndbm.h file
Missing ndbm.h file
Product: Red Hat Linux
Classification: Retired
Component: gdbm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
Depends On:
  Show dependency treegraph
Reported: 1999-05-03 19:43 EDT by caperry
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-05-14 16:15:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description caperry 1999-05-03 19:43:11 EDT
The file ndbm.h is missing from this package.  It is
included with the gdbm source from GNU, but it is not in any
packages.  Apache + mod_ssl and/or mod_rewrite requires that
Comment 1 Jeff Johnson 1999-05-04 10:40:59 EDT
There are several different ndbm emulations (e.g. db1 and db2) that
would like the honor of being THE ndbm.h. Try using db1 by
including <db1/ndbm.h> and linking with -ldb1.

GDBM also has a GPL rather than a LGPL license.
Comment 2 niles 1999-05-06 16:43:59 EDT
This is unacceptable!  The Open Group's single UNIX spec
clearly idenitifies the path as <ndbm.h>.  So there needs to
be a choice made and a symbolic link added at least.  There
must exist a file /usr/include/ndbm.h to meet the UNIX spec.
Comment 3 caperry 1999-05-06 17:55:59 EDT
I still do not understand why the ndmb.h file from the gdbm library
cannot be used.  Recompiling with a different library causes much more
grief than it's worth, especially if you are using a huge package like
Apache with mod_ssl.  ReWriting all those makefiles to use db1 or db2
just seems foolish with the file from the gdbm package works out of the
box.  Does it really matter if the package is GPL or LGPL, especially
since it's already in the distribution.  Why can't the distribution be
Comment 4 ct7 1999-05-12 17:25:59 EDT
Previously RedHat shipped this in glibc-devel-2.0.7-29.i386.rpm; why
isn't it being shipped now in glibc-devel-2.1.1-6.i386.rpm?  This is a
lousy way to treat people who are upgrading from previous versions --
I'm sure I could go back through all of my older RH5.X disks and find
that ndbm.h was in /usr/include ... why move it now?

The GPL license shouldn't be an issue since the GNU libraries are
being delivered as part of the base operating system.
Comment 5 Jeff Johnson 1999-05-14 16:15:59 EDT
There is no way that Red Hat can supply an ndbm.h without
annoying someone. As I said before, there are several different
candidates (e.g. gdbm, db1, db2) that supply a ndbm emulation,
each of which has an incompatible database format.

Choose which database format works for you and create a symlink to
/usr/include/ndbm.h. For example, if you want db1 emulation then do as
	ln -s db1/ndbm.h /usr/include/ndbm.h
Comment 6 smanes 1999-08-05 13:21:59 EDT
This solution (link db1/ndbm.h to /usr/include/ndbm.h) won't fix the
Perl 5.005.03 compile problems.  Apparently, the db1 NDBM library
doesn't permit null keys, which Perl supports in its hashes. That's
what is causing the anydbm.t test failures anyway, i.e.

$h{''} = "bar";
print ($h{''} eq 'bar' ? "ok 12\n" : "not ok 12\n");

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