Bug 2527
Summary: | Missing ndbm.h file | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | caperry |
Component: | gdbm | Assignee: | David Lawrence <dkl> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | CC: | ct7, smanes |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 1999-05-14 20:15:35 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
caperry
1999-05-03 23:43:11 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. 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. 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? 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. 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 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"); |