Jay Buhner wrote:
The second problem is that recent versions of the gdbm
library have moved the dbm compatibility routines to
the gdbm_compat library. I modified configure.in to
check for this and link with the appropriate
libraries.
The relevant fragment of the patch being:
--- configure.in.orig 2005-02-23 08:20:47.000000000 -0800
+++ configure.in 2005-12-03 18:16:00.000000000 -0800
@@ -595,8 +595,13 @@
AC_CHECK_LIB(ndbm, dbm_open, ,
AC_CHECK_LIB(dbm, dbm_open, ,
AC_CHECK_LIB(db1, dbm_open, ,
- AC_CHECK_LIB(gdbm, dbm_open, ,
- AC_CHECK_LIB(db, __db_ndbm_open))))))
+ AC_CHECK_LIB(db, __db_ndbm_open, ,
+ AC_CHECK_LIB(gdbm, dbm_open, ,
+ AC_CHECK_LIB(gdbm_compat, dbm_open, , , -lgdbm)))))))
+
+if test "$ac_cv_lib_gdbm_compat_dbm_open" = yes; then
+ AC_CHECK_LIB(gdbm, gdbm_open)
+fi
dnl ----------------
dnl CHECK FOR NDBM.H
I note that the current configure.in doesn't get debian stable
(with libdb4.2-dev) right either, because it uses __db_ndbm_open_4002
rather than __db_ndbm_open as the underlying function for dbm_open().
(Currently there's a patch in the debian package which overrides this
check and hardwires the right answer.)
This whole area of checking for libdb seems to be a tremendous mess;
for example look at this enormous pile of autoconf that claims to do it:
http://ac-archive.sourceforge.net/Installed_Packages/ax_path_bdb.html
(not directly helpful to us since it's GPLed).
My inclination is to say that we should replace this growing nest
of AC_CHECK_LIB functions with something using AC_LINK_IFELSE; that
way we can define DB_DBM_HSEARCH and check for dbm_open rather than
fiddling around looking for internal __ symbols.
-- PMM
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers