This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


>>>>> Michael Marxmeier writes:

Sorry, it seems that I've confused you.  The mail you're answering to
went to a glibc developers list to discuss your report.

MM> Hello Andreas.
MM> Andreas Jaeger wrote:
>> Is there anything we can do about this problem?
>> 
>> The obvious solutions are:
>> - disable nss_db
>> - don't use proprietary software that you can't recompile
Upps, I forgot a smiley ;-)

MM> Obvious and all true ... but the question is, should the usage 
MM> of the nss db service (or any other process which is supposed to
MM> be transparent) change the behaviour of the libc in a way that the
MM> application can't predict? 

>> From the application point of view i'd say no. That's the reason
MM> why the various standards have defined a namespace for the libc
MM> and applications so there is a border line.

MM> This does not affect only closed source software but could also
MM> hit an open sw which may not use the current db library version 
MM> for whatever reason (eg. different API).

MM> This specific case is certainly a corner case because the same 
MM> library (which uses reserved name space) is part of libc but also 
MM> common in applications, possibly in different versions.

>> Or should this work with glibc 2.2?

We're reworking the db support currently - glibc 2.2 will handle it
differently than glibc 2.1 does.  This question was meant for Ulrich.


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

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]