Re: DB3 symbol collisions solved...
On Thu, 16 Nov 2000, Ben Collins wrote:
> > $ 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.
>
> You are misunderstanding how this works. When the dynamic loader binds
> these, it uses direct linkage. What you are assuming is that your case
> above is linked to both libdb3 and libdb2, when in fact it isn't. Watch
> this:
Er, no he isn't. Look at what he has done and look at the result. He made
a program just like slapd that is linked to db3 but is really using db2
when sasl is involved. He has proved this by the simple fact that the
db_version symbol gets linked to db2 in his test program in the presense
of sasl.
Now unless he is not using your modified db3 this is conclusive proof that
your method does not do what you think it does! I think he is using your
db3 because otherwise this situation would select the db3 symbol for his
test program.
This makes sense because you have made all the db3 symbols weak, db2's
stronger symbols will override them in the global symbol table - the
dynamic linker does not do scoped lookups, it brings shared libary symbols
into a single global symbol table.
Why this doesn't seg for slapd is because you have made db2 prefered over
db3 (db3's weak symbols are overwritten by the stronger ones in db2),
without your scheme link order will make this reversed. I suspect if you
look closely at the db2/db3 api differences you realize one way has a
greater chance of seging.
Lack of segfaulting is not a sufficient means to prove that this method is
working, print out the addresses of all the db symbols from within slapd
and within sasl when they are combined and prove they are different.
(this is really the same as Xu's use of db_version, but more complete
since it shows all symbols are different)
> blimpo:~# ldd /usr/sbin/slapd | grep libdb
> libdb-3.1.so => /usr/lib/libdb-3.1.so (0x70084000)
> libdb2.so.2 => /usr/lib/libdb2.so.2 (0x70360000)
>
> blimpo:~# objdump --all /usr/sbin/slapd | grep NEEDED | grep libdb
> NEEDED libdb-3.1.so
>
> blimpo:~# objdump --all /usr/lib/libsasl.so.7.1.8 | grep NEEDED | grep libdb
> NEEDED libdb2.so.2
>
> Notice the *actual* linkage for slapd, is to libdb3, and the *actual*
> linkage for libsasl is to libdb2. The elf loader knows this, and handles
1) His sasl is the same as your sasl.
2) His ./a.out is linked to db3.
He'd have to be using one screwed up tool chain to get any other result
from the objdump output.
Jason
Reply to: