Sam Varshavchik writes:
Alessandro Vesely writes:
Well, I'm not going to install this stuff. That's just adding more
stuff that can break. And, I'm sure this will break configure for BDB < 4.
Please think twice. Detecting BDB is often a nuisance when building various
packages. Besides Courier, Apache, Xemacs, and OpenLDAP have their own
more or less complicated m4 macros. Spreading those resources does not
improve the overall quality of Autoconf generated scripts.
This is what happens when BDB changes APIs several times a year.
Yes, the cat never sleeps... I complained about that to their feedback
mailbox (and still CC to them) and got a reply from former CEO Mike Olson.
He agrees that they should produce an m4 macro to support Autoconf. IMHO,
the macros above are a good start and I sent those pointers also to him.
(There is a different approach: enumerating each known version. It won't
work with _future_ versions, but that's what do Apache and the reusable
http://autoconf-archive.cryp.to/berkeley_db.html )
Configure works for me for bdb 4.3. If it breaks when I upgrade to a
newer BDB, I'll fix it then.
It doesn't work with 4.1 and 4.2: I get the following...
$ strings /usr/lib/libdb3.so.3.0.2 | grep db_env_create
__db_env_create_1
db_env_create
$ strings /usr/lib/libdb-4.1.so | grep db_env_create
__db_env_create_4001
$ strings /usr/lib/libdb-4.2.so | grep db_env_create
__db_env_create_4002
$ strings /usr/lib/libdb-4.3.so | grep db_env_create
__db_env_create_4003
db_env_create
...and cannot guess the trend.
In case Courier-authlib is updated less often than BDB, as it should,
its configure script must be able to handle new BDB versions. Those
were future at script generation time. An "official" m4 macro should
not break when a new version is compatible with the old client source.