Re: BerkeleyDB Perl module on potato (slightly long)
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
Reply to: