I have a sinking feeling that the C library in Mac OS X was called something exotic, like "System" (libSystem.dylib). If that's the case, you may need to use something like that instead of "c".
You are right about that. I couldn't change the patch directly (patch seems to know if a patch is altered) so I just made the changes in dbm.m4 itself after applying the patch. (Also, in Darwin, it's db.h, not db_185.h although I have reason to believe it is nevertheless 1.85).
Which version of Mac OS X? Does this patch resemble what worked? If so, good
for someone to commit?
I'll leave that to the experts, but for those rare instances where someone might choose db1 over db4, sdbm or the other choices, it sounds like a good idea. The patch below looks correct, yes -- it is exactly how I changed dbm.m4 after applying the patch (which maybe was redundant but anyway it told me exactly what lines to change; maybe you could say I applied the patch manually but the patch semantics helped me do it exactly right ;-).
I am running Panther 10.3.3. (Will update to 10.3.4 tonight.)
Explicitly naming libSystem is ugly; it would be better to have a way to try "no
library", a la AC_SEARCH_LIBS. I think avoiding the need to patch the generic
BDB detection code to accommodate this corner case trumps the ugliness, however.
diff -u -r1.9 dbm.m4 --- dbm.m4 13 Mar 2004 04:33:54 -0000 1.9 +++ dbm.m4 26 May 2004 21:02:58 -0000 @@ -298,8 +298,8 @@ fi APU_CHECK_BERKELEY_DB(1, -1, -1, "$places", - "db_185.h", - "db" + "db_185.h db.h", + "db System" # libSystem on Mac OS X incorporates DB1.85 ) if test "$apu_have_db" = "1"; then apu_db_version=185
-- Brent Gulanowski [EMAIL PROTECTED]
