Re: Latest Glibc from CVS has segmentation problems.

["Patrick J. LoPresti" <patl at users dot sourceforge dot net>]

No flames this time.

Danilo Segan <dsegan@gmx.net> writes:

> With the risc of furthering this flamewar (I'm not taking any
> position here), I'll remind you that modules are statically linked
> objects, just like the kernel is.  If they're used, they're also
> statically in memory -- they do not move during runtime (unless if
> you do insmod, rmmod).

Modules can be loaded and unloaded as needed.

> I agree that _I_ (not that it matters, since nobody asked me for
> opinion) cannot imagine how to make this work without loading complete
> library in memory (so runtime doesn't get affected with files changing
> in the filesystem), or arranging a messy setup of dual libc
> installations on one system (which would take a lot of work, because
> shared libraries are not in-memory objects like kernels, you'd need to
> do some dancing with symbolic links I think), or modifying init
> scripts temporarily to install entire libc before any libc-depending
> program is started (but this doesn't allow for keeping two libc setups).

When I do "make install-modules" in a Linux source tree, and then I
try to load a module, do you know what happens?  I get the OLD module.

That's because "make install-modules" does not install on top of the
current module set; it installs in a separate directory named after
the kernel version.  So yes, I am suggesting that you be able to have
multiple copies of the C library on your disk simultaneously, just
like you can have multiple kernels and module sets on your disk
simultaneously.

This is not rocket science.

> If you want to compare, get yourself enough privileges, and try
> overwriting your current running kernel with a new image directly in
> memory.

"make install" does not even overwrite the kernel on disk!  It simply
installs the new one next to the old.  When you want to use it, you
change one line in your boot loader configuration and reboot.

Something similar could be done for libc quite easily.  I am not an
expert, but I think the easiest approach would be to use a single
symlink (just /lib/ld-linux.so.2 would do, I believe) to control which
dynamic C library you are using.  People who want to live on the edge
could change that symlink on a running system.  But the normal and
recommended approach would be to set it during "early userspace"; that
is, immediately after booting the kernel.

The "early userspace" binaries would have to be statically linked, of
course.  But this is not rocket science, either.  For example, klibc
already includes "ash" and "ln" which would be sufficient.

> My entire point here is: kernel is easier to replace than a
> component like libc in modern GNU systems.

And my point is that this is a direct consequence of how each system
was designed.  It is not endemic to either.

 - Pat