[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] patches to the nmh-1.1-RC4 version of configure.in

From: pmaydell
Subject: Re: [Nmh-workers] patches to the nmh-1.1-RC4 version of configure.in
Date: Sun, 11 Dec 2005 17:32:25 +0000

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

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)
 dnl ----------------

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:
(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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]