Am 21.12.2012 00:08, schrieb Michael Elkins:
> On Thu, Dec 20, 2012 at 06:06:10PM +0100, Matthias Andree wrote:
>> Am 20.12.2012 16:20, schrieb Michael Elkins:
>>> 1.1 --- a/configure.ac Thu Jul 22 20:06:33 2010 +0200
>>> 1.2 +++ b/configure.ac Wed Dec 19 14:40:24 2012 -0800
>>> 1.3 @@ -993,7 +993,7 @@
>>> 1.4 bdbpfx="$bdbpfx $d/$v"
>>> 1.5 done
>>> 1.6 done
>>> 1.7 - BDB_VERSIONS="db-4 db4 db-4.6 db4.6 db46 db-4.5
>>> db4.5 db45 db-4.4 db4.4 db44 db-4.3 db4.3 db43 db-4.2 db4.2 db42
>>> db-4.1 db4.1 db41 db ''"
>>> 1.8 + BDB_VERSIONS="db-4 db4 db-5 db5 db-5.2 db5.2 db52
>>> db-5.1 db5.1 db51 db-5.0 db5.0 db50 db-4.8 db4.8 db48 db-4.7 db4.7
>>> db47 db-4.6 db4.6 db46 db-4.5 db4.5 db45 db-4.4 db4.4 db44 db-4.3
>>> db4.3 db43 db-4.2 db4.2 db42 db-4.1 db4.1 db41 db ''"
>>> 1.9 AC_MSG_CHECKING([for BerkeleyDB > 4.0])
>>> 1.10 for d in $bdbpfx; do
>>> 1.11 BDB_INCLUDE_DIR=""
>>>
>>
>> Whoever did this, this is way excessive, even in the light of rampant
>> renaming of libdb, and it Does Not Even Workâ˘.
>>
>> You end up with 456 (literally!) gcc -o conftest ... runs but none comes
>> up with a db. I have perfectly working DB 4.1, 4.8 and 5.3 installed,
>> and you should think it would have picked one up at least. But no.
>
> Suggestions for cleaning that up are welcome. As I understand it, the
> main problem here is FreeBSD which supports the installation of multiple
> development versions. Of the Linux-based OS's that I've tested, you can
> typically expect that /usr/include/db.h and -ldb are a newish BDB. But
> on FreeBSD, that will get you a much older version. So much work is
> done to hunt for a newer version...
It is not FreeBSD specific - Ubuntu Linux and openSUSE Linux permit
multiple DB packages, and NetBSD does, too.
For FreeBSD, BerkeleyDB <= 4.1 was a royal pain, as it is for NetBSD
today. I have made it much simpler for the remaining Berkeley DB
versions 4.2 and up on FreeBSD, starting back in 2004.
These are the files installed by Berkeley DB 5.3 (databases/db5) on FreeBSD:
/usr/local/include/db5/db.h
/usr/local/lib/db5/libdb-5.3.a
/usr/local/lib/db5/libdb-5.3.la
/usr/local/lib/db5/libdb-5.3.so -> libdb-5.3.so.0
/usr/local/lib/db5/libdb-5.3.so.0
/usr/local/lib/db5/libdb-5.so -> libdb-5.3.so
/usr/local/lib/db5/libdb.a -> libdb-5.3.a
/usr/local/lib/db5/libdb.so -> libdb-5.3.so
/usr/local/lib/libdb-5.3.so -> libdb-5.3.so.0
/usr/local/lib/libdb-5.3.so.0 -> db5/libdb-5.3.so.0
/usr/local/lib/libdb-5.so -> db5/libdb-5.so
/usr/local/lib/libdb-5.so.0 -> libdb-5.3.so.0
And the good thing is: no matter against which of the *.so* files you
link, SONAME is always libdb-MAJOR.MINOR.so, f. i. libdb-5.3.so, and
that is what gets recorded as "NEEDED" in mutt, and solves all run-time
headaches.
For FreeBSD, let M be the major and m the minor version of Berkeley DB,
then:
1. add -I/usr/local/include/db4m or -I/usr/local/include/db5 to CPPFLAGS
2. add -L/usr/local/lib/db4m or -L/usr/local/lib/db5 to LDFLAGS
3. link with -ldb-M.m
And that's it.
NetBSD, however, renames the libraries, so it is more of a hassle:
- Berkeley DB 5.3: .../include/db5/db.h, .../lib/libdb5.so
- Berkeley DB 4.8: .../include/db4/db.h, .../lib/libdb4.so
- Berkeley DB 4.6: .../include/db46/db.h, .../lib/libdb46.so
I haven't looked at DragonflyBSD or OpenBSD.
By constrast, the stock Berkeley DB layout is, for instance.
/usr/local/BerkeleyDB.5.2/include/db.h
/usr/local/BerkeleyDB.5.2/lib then contains
libdb-5.2.a
libdb-5.2.la
libdb-5.2.so
libdb-5.so -> libdb-5.2.so
libdb.a
libdb_cxx-5.2.a
libdb_cxx-5.2.la
libdb_cxx-5.2.so
libdb_cxx-5.so -> libdb_cxx-5.2.so
libdb_cxx.a
libdb_cxx.so -> libdb_cxx-5.2.so
libdb.so -> libdb-5.2.so
CSW follows this layout with a different prefix
(/opt/csw/bdb48/{include,lib}).
Now, my strategy would be:
1. go find the db.h include file.
2. derive the major and minor version components from it.
3. go find the db-major.minor.so file. If this fails, go to 1 to find a
different db.h file.
And usually you can make an educated guess from the include path to the
library path, it's either sed s,include,lib, or sed
s,include/db[^/]\+,lib, - in the end it should be much faster (fewer
checks) and always match the library to the headers.
I can try to write this up as configure.ac snippet later, time
permitting, if you are willing to take such a change (I'd grab the
existing path search list). If you don't like the concept, I'll save
myself the hassle :)
