I've been trying to build Apache 1.3.14 from tarball on Linux 7.0 using DSO. The problem comes with mod_auth_db. Trying httpd -t gives Cannot load /etc/httpd/modules/mod_auth_db.so into server: undefined symbol: db_open The problem is that I didn't build the box. Somebody else did and did a selective install of what he thought would be needed. So to figure out where the problem was, I put on a tarball of 1.3.12 that I've successfully used on 6.2 and used my standard .configure options. That failed with the same problem. That seems to eliminate changes between 1.3.12 and 1.3.14 as the problem. I did an RPM database dump of glibc and looked for the Berkeley db stuff, since I figured that was the most likely problem. I couldn't see it. So I hauled the sources of 2.7-7 from Sleepycat and installed them. Later, of course, I found the db stuff split off from glibc. Nothing I try seems to work. I've re-installed db1, 2 and 3 with --force. I still can't find a db.h for db3 (which may be the root of the problem). Maybe the install of db2-2.7.7 was the problem. There's a /usr/include/db.h for 2.7.7, so I removed it (after first doing a dump of the entire RPM database to check that it shouldn't be there). Then make said that mod_auth_dbm complained it couldn't find that file. So I soft linked it to the glibc equivalent (after checking it was the right thing). Apache compiled. And after all that, db_open still can't be found by mod_auth_db.so. I can't find any RPM that provides a db.h for db3. From what I understand of the code, mod_auth_db checks DB_MAJOR_VERSION so shouldn't be trying to use the db3 routines anyway. I've tried loads of other things mentioned in the Apache bugs database to work around problems with mod_auth_db in earlier versions, just on the off-chance. I checked the Red Hat database. I've tried the suggestion to use -gdbm to resolve problems with mod_perl being built with db3. I am trying to include mod_perl in 1.3.14, but I tried leaving it out. Same problem. Just rechecked with 1.3.12 using my standard config options (no mod_perl) and the problem is still there. Any ideas?
The db.h for db3 should be in the db3-devel subpackage (as /usr/include/db.h). There are some issues that crop up when you have multiple dbX-devel packages installed which make an Apache build procedure get strange (the configure script finds libndbm.so, provided by db2-devel, and thus links in db2, and then links in db3 because it provides libdb.so).
Can you tell me where the header file for each db package should live? Looks like I have the db2 header in /usr/include. If you can confirm that should be the db3 header then I have problems and the others could be in the wrong places.
The /usr/include/db.h header is part of db3-devel (which matches what you get when you link using -ldb). All of the other header files for versions of Berkeley DB should be located under /usr/include/db1 or /usr/include/db2 or /usr/include/db3, respectively.
Just checked the output of rpm -qail. It has the following db.h files supplied by package compat-glibc: /usr/i386-glibc21-linux/include/db.h /usr/i386-glibc21-linux/include/db1/db.h None of the sleepycat db1, 2 or 3 packages supply a db.h. Nothing else in that rpm listing supplies a db.h. Do these come from some other package the guy who built the box didn't install or did the splitting out of the sleepycat stuff from glibc cause some header files to get lost? Or am I losing the plot?
The db1/db2/db3 packages only supply shared libraries. The headers and static libraries are in db1-devel/db2-devel/db3-devel, which apparently were not installed when the system was built. These can be gotten from ftp://ftp.redhat.com/redhat/releases/guinness/i386/en/RedHat/RPMS/ or the equivalent directory on a mirror.
Got the sources. Did a --rebuild on them to get the devel rpms (it apears only db1-devel is on the 7.0 CD). Did an rpm --Uvh --force on all of the db rpms generated by the rebuilds, not just the devel ones. Did a make clean, configure, make, make install on Apache. Uncommented the auth_db lines in httpd.conf. Same error - cannot find symbol for db_open.
Thanks for the report. This is a mass bug update; since this release of Red Hat Linux is no longer supported, please either: a) try and reproduce the bug with a supported version of Red Hat Enterprise Linux or Fedora Core, and re-open this bug as appropriate after changing the Product field, or, b) if relevant, try and reproduce this bug using the current version of the upstream package, and report the bug upstream.