This is the mail archive of the libc-alpha@sources.redhat.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]
Other format: [Raw text]

Re: binary incompatible change in libnss_*.so.2


On Tue, Apr 09, 2002 at 10:18:15PM +0200, Thorsten Kukuk wrote:
> On Tue, Apr 09, Ulrich Drepper wrote:
> 
> > On Tue, 2002-04-09 at 09:21, Bruno Haible wrote:
> > 
> > > After installing glibc-20020408 (built with gcc-3.0.4, on a SuSE 7.3 i386
> > > system) "su" and "login" don't work any more, because dynamic loading of
> > > /lib/security/pam_unix.so fails. The reason are unsatisfied symbols.
> > > Last time, with glibc-20020115, there was no problem.
> > 
> > The PAM module is using a NSS module directly which isn't allowed.  The
> > NSS modules don't provide a user ABI, only the nSS routines in libc are
> > allowed to use them.
> 
> Why do we have a major version number for it and increased it in the
> past for binary incopatible changes?

Did we bump libc.so version number any time some exported, though
considered private, function changed (I mean here all the symbols now
marked as GLIBC_PRIVATE, those were changing in the past
even between dot releases)?

> Why is this called "libnss*" and not "nss*"  like Solaris does?

I think there are tons of dlopen-only modules in linux which start with lib
that this doesn't imply anything. IMHO NSS modules are just modules;
allowing other libs/apps to link against it ties glibc's hands, because it
is not able to change/optimize the implementation at will.

> The reason (you self explained it!) is,
> that in this way it is possible to link against this libraries. Why
> did you change your opinium about this?

Cannot find any such explanation above.

	Jakub


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