Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 2527 - Missing ndbm.h file
Summary: Missing ndbm.h file
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdbm
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-03 23:43 UTC by caperry
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-05-14 20:15:35 UTC


Attachments (Terms of Use)

Description caperry 1999-05-03 23:43:11 UTC
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
file.

Comment 1 Jeff Johnson 1999-05-04 14:40:59 UTC
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 20:43:59 UTC
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 21:55:59 UTC
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
complete?

Comment 4 ct7 1999-05-12 21:25:59 UTC
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 20:15:59 UTC
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
root
	ln -s db1/ndbm.h /usr/include/ndbm.h

Comment 6 smanes 1999-08-05 17:21:59 UTC
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.