Re: libc/1508: symbol conflict due to nss_db.so usage of /lib/libdb.so.3

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Andreas Jaeger <aj@suse.de>
   Date: 04 Jan 2000 11:10:27 +0100

Michael, please pay attention and provide us with the information I'm
requesting below.

   MM> Don't know. I can imagine two aproaches:

   MM> 1. "Don't do that".  The issue could be documented and forgotten.
   MM> However i could imagine this or a similar issue could come back 
   MM> and hit again.

   MM> 2. There should be an option to assure that libc components do 
   MM> not call other libraries besides the defined interfaces (which
   MM> __db_calloc() is not). This would also enforce the libc interfaces 
   MM> and sanity. OTOH this would make LD_LIBRARY_PRELOAD less helpful.

   __db_calloc is not called directly from glibc at all.  Have a look at
   the stacktrace and the source.  nss_db_open is an alias for db_open -
   glibc just calls db_open in nss_db/db-XXX.c

More correctly, db_open is a weak alias for __nss_db_open and we only
call __nss_db_open from nss_db module.  The name __nss_db_open is
clearly within the namespace owned by glibc, nobody else should be
messing with __nss_ prefixed names!  This basically should have the
effect of approach 2.

That's why I don't understand what's happening here.  The symbol
__db_calloc has only local scope in the libdb.so.3 that comes with
glibc.  So there is no way that a call to __nss_db_open in our
lidb.so.3 could end up in the __db_calloc in Netscape's libdb.so.  In
order to make sure this is really true, Michael, could you send us the
output of:

   $ nm /lib/libdb.so.3 | grep __db_calloc

If the above if true, this means, that either:

 * The segmentation fault is not related to the two different db libs
   (or at least not in the way Michael suggests).

 * Somehow, the call to __nss_db_open ends up in Netscape's libdb.so.
   That means that either Netscape did something incredibly stupid:
   They distributed their libdb.so with a symbol named __nss_db_open.
   To check this, Michael, could you send us the output of:

      $ nm /netscape/server4/lib/libdb.so | grep __nss_db_open

   Or the dynamic linker messes things up by not only relocating
   db_open to the db_open in Netscape's libdb.so but also pointing
   __nss_db_open to db_open in Netscape's libdb.so.

Mark