Re: DB3 symbol collisions solved...
On Wed, Nov 15, 2000 at 04:18:08PM -0500, Ben Collins wrote:
> >
> > Sorry but it's still unclear to me. If I've linked with both libdb3-dev
> > and libsasl7-dev which was linked with libdb2-dev, then when I run it,
> > it'll load both libdb2 and libdb3. Since the libdb3 symbols are weak,
> > it'll end up only using the ones from libdb2, for both the symbols required
> > by libsasl7 and my own program. Right?
> >
> > I just don't see how you can distinguish between the symbols needed by
> > libsasl7 and the symbols needed by the program itself.
>
> See, you aren't listening. They are weak *aliases* to the normal "munged"
> db3 symbols. Trust me, if it were using the db2 symbols, it would crash,
> which is the problem we would have, had this not been implemented.
How about actually reading my messages rather than accusing me of not
listening to you?
OK, I dusted my keyboard and wrote some code:
#include <db.h>
#include <stdio.h>
int main() {
printf("%s\n", db_version(0, 0, 0));
return 0;
}
I've got libdb3 and libdb3-dev installed (well OK, I haven't got libdb3-dev
installed due to the dpkg-dev conflict, but I've got it in my search path).
$ gcc a.o -o a -ldb -lsasl
$ ldd a
libdb-3.1.so => /usr/lib/libdb-3.1.so (0x40020000)
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x40099000)
libc.so.6 => /lib/libc.so.6 (0x400a4000)
libdb2.so.2 => /usr/lib/libdb2.so.2 (0x401af000)
libdl.so.2 => /lib/libdl.so.2 (0x401f3000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401f6000)
libpam.so.0 => /lib/libpam.so.0 (0x40223000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ./a
Sleepycat Software: Berkeley DB 2.7.7: (08/20/99)
$ gcc a.o -o a -ldb
$ ldd a
libdb-3.1.so => /usr/lib/libdb-3.1.so (0x40020000)
libc.so.6 => /lib/libc.so.6 (0x40099000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ./a
Sleepycat Software: Berkeley DB 3.1.17: (November 15, 2000)
Sure, if you're lucky it will work for a while. But if you're like me
you'd be pretty nervous if your mail server (or whatever) was compiled with
libdb3-dev but is actually running with libdb2.
Personally I think the simplest solution is to make libdb3-dev conflict
with versions of libsasl-dev (and others if necessary) that were linked
with libdb2. This wouldn't have been needed if libsasl-dev actually
declared its dependency on libdb2-dev, which we should probably add to our
policy if it isn't there already.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: