This is the mail archive of the
mailing list for the glibc project.
Re: upgrade problem
On Thu, Nov 09, 2000 at 09:46:54PM +0100, Frederic Lepied wrote:
> Andreas Jaeger <firstname.lastname@example.org> writes:
> > >>>>> Frederic Lepied writes:
> > > What I plan to do for Mandrake is keep the libnss from old glibc until
> > > the reboot. For that I have to change the soname of the libnss of the
> > > new glibc to avoid name clashes. WDYT ?
> > If you like to have a distribution that's incompatible to the rest of
> > the world - go ahead. But don't expect any support from the glibc
> > developers for this and for the problems that will arise.
> It is just an idea but I don't see why it can break things: no application
> as far as know link directly with the dynamic libnss*. So why is it a
> problem to call the soname libnss*.so.2.2 instead of libnss*.so.2 ?
I'm not saying the soname should change. I'm saying that maybe a fall back
to a different *file name* would be usable.
Here's the scenario:
- Start application rund, built and running under glibc 2.1.3.
- Later while the application is still running, upgrade libc to 2.1.97
- This application is a network application, and it now receives a
connection and forks to handle it.
- After forking, it does a getpwnam() using the supplied name from the
network client. When it does this, it loads the appropriate NSS modules
*on disk*, resolving the modules symbols using the libc.so.6 *in memory*
(IOW, glibc 2.1.3).
- Now this module that is loaded was compiled against 2.1.97, and uses
some GLIBC_2.2 versioned symbols which are not in the libc.so.6 that the
application has in memory, so the module load fails.
This is fixed by restarting the application, but that's a nightmare for
distributions concerned about upgrades (and asking the user to restart is
not the best face you want to show, being the Linux is touted for not
beeding reboots except for new kernel's).
Does this clarify?
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` email@example.com -- firstname.lastname@example.org -- email@example.com '