On Tue, Apr 03, 2001 at 11:49:39PM +1000, Andrew Pollock wrote: > I've spent some time trying to get the BerkeleyDB module to build on > potato (and been quietly going insane in the process).
I think more has been made of this problem than it deserves... > I've got libc6, libc6-dev, libdb2 and libdb2-dev from woody installed. > > I've successfully built the BerkeleyDB module, but on running the tests I > get: > > BerkeleyDB needs compatible versions of libdb & db.h > you have db.h version 2.7.7 and libdb version 2.4.14 > > At this point, I scream at my computer, harass the libdb2/libdb2-dev > package maintainer etc etc, but after rereading this chunk of the README > for the BerkeleyDB Perl module: > > Newer versions of Linux (e.g. RedHat 6, SuSe 6) ship with a C library > that has version 2.x of Berkeley DB linked into it. The BerkeleyDB author is a little confused. The C library does not have libdb linked to it; as far as I know, it never has. It may try to dynamically load libdb for the nsswitch stuff, but this is a completely separate problem that is not involved here (and, from what I've heard, has been worked around in Debian). > This makes it > difficult to build this module with anything other than the version of > Berkeley DB that shipped with your Linux release. If you do try to use > a different version of Berkeley DB you will most likely get the error > described in the "Incompatible versions of db.h and libdb" section of > this file. > > The penny finally dropped tonight. Perl's linked against something > different: > > daedalus:~/.cpan/build/BerkeleyDB-0.14# ldd /usr/bin/perl > libnsl.so.1 => /lib/libnsl.so.1 (0x4001b000) > libdb.so.3 => /lib/libdb.so.3 (0x40030000) > libgdbm.so.1 => /usr/lib/libgdbm.so.1 (0x4006c000) > libdl.so.2 => /lib/libdl.so.2 (0x40072000) > libm.so.6 => /lib/libm.so.6 (0x40075000) > libc.so.6 => /lib/libc.so.6 (0x40093000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x401a2000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Yes--it is perl that is linked against libdb, not the C library. This is the problem. And it is a stupid problem--because perl doesn't need to be linked against libdb. I suspect it is an artifact of the famously intricate perl build process. [debugging snipped] > So while I'm building my BerkeleyDB stuff against the right BerkeleyDB > libraries and stuff, Perl itself appears to be hardlinked against an older > libdb. yup > (For the heck of it I symlinked /lib/libdb.so.3 to /usr/lib/libdb2.so.2, > lo and behold, the module started working (it passed a "make test" at > least), but things like Sendmail's makemap started bleating). Exactly--because perl itself doesn't need libdb at all, so it couldn't care less which libdb it links to. Programs that actually use libdb, on the other hand ... :-) > So, how screwed am I? Do I have to roll my own Perl? Do I have to resort > to other feral workarounds as described in the README that comes with the > module? It's really simple: get the perl maintainer to convince perl to build without linking to libdb. > In short, has anyone else been here? I went through this several months ago, found a resolution, and fired off an explanation to Paul Marquess (BerkeleyDB author). Unfortunately, the mail bounced due (as I found later) to a mailer config error, and by the time that was resolved, the issue was out of my mind. Doh. I will resend my message to Paul Marquess and Cc: this list for those that are interested. Andrew
