[Vserver] [glibc] Usage of glibc with VServer tools

From: Michael S. Zick <mszick_at_morethan.org>
Date: Fri 03 Feb 2006 - 16:14:24 GMT
Message-Id: <200602031014.24228.mszick@morethan.org>

Group,

An update on the discussions in m-l threads:
re: http://list.linux-vserver.org/archive/vserver/msg09336.html
re: http://list.linux-vserver.org/archive/vserver/msg12349.html

At the time of this writing, there are a lot of distributions which
have glibc-2.3.2 deployed (Debian/Sarge for one).
The glibc project has released glibc-2.3.6 recently.

There are distributions which have deployed all versions inbetween,
complicated by distribution specific patches.

If that is not confusing enough, even the same distribution may not
use the same version of glibc (and with the same build options) depending
on the system hardware.
For example, a Debian/Sarge/parisc and a Debian/Sarge/x86 system does
not deploy the same glibc with the same options.

The VServer tools are a combination of low level, compiled tools and
high level, Bash scripts. Both of which need to lookup names.
These programs expect the name lookup functions to be supplied by
the system library[1].

When executing within the host (0) context, the host system library
will be used.
When executing within the guest (>1) context, the guest system library
will be used.

The problems encountered in the referenced m-l threads are related to
when a process has to execute in both/either context(s).
Such behavior happens during the creation of and/or entry into a guest
context.

This is due to there being no guarantee that the libraries in the host
and the guest have compatable name lookup implementations.

Enforcing such a guarantee is not an option - the guest context should
be able to run any system library that is compatable with the host kernel.

One work-around is to staticly link the VServer tools - this 'hardcodes'
the name lookup implementation to whatever code the library used for
linking provided.

But what about the copy of Bash that is running the high level scripts?
Ah, so...

Building a staticly linked[2] copy of Bash-3.1 provides a set of warning
messages - pointing to the culprits:

<quote>
warning: Using 'getgrent' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking.
</quote>

With the same warning for:
setgrent, endgrent, getpwent, getpwnam, getpwuid, setpwent, endpwent,
getaddrinfo, getservent, setservent, endservent

There might be others, those are the ones that Bash-3.1 complains about.

Since this warning is related to how glibc implements those functions (in
an external DSO), it applies to any program that makes those function calls
and staticly linked against glibc-2.3.{2,3,4,5,6} even if that program's
build does not report the warnings.

The staticly linked Bash-3.1 will run, without runtime error reports, with
those calls not present. Of course, those functions will not work, but
Bash-3.1 will survive.

The Bash-3.1 config-bot.h may be modified to avoid the features that call
those functions. But that is not the real solution, the VServer tools
need to call those functions also.

The solution is to include some 'linker magic' in the build of Bash (and
the VServer tools) to include the glibc static library implementation of
those calls.

I have not determined that 'linker magic' yet - but the static archives
are present, even with Debian/Sarge binary only, installations.

- - - - -

Notes:

[1] Which flavor of glibc am I building against?

On your VServer tools build system, examine a dynamicly linked application;
your distribution's Bash is probably dynamicly linked, use the ldd script:

enter: ldd /bin/bash

If you see a: linux-gate.so.1 => (high memory address)
then the program is linked to use the kernel's 'fast sys-call' entry.
This is a kernel code provided, virtual, DSO - there should not
be any such file on the system.

Note the actual location of libc.so.6 (on the right of the => thing);
execute the actual library:
(Debian/Sarge/x86 - your milage will vary)

enter: /lib/tls/libc.so.6

Which will report some identifying information.

Determine the library binaries by:
enter: cat /usr/include/gnu/lib-names.h

It is the static libraries for libnss_dns*, libnss_files*, and
libnss_compat* that will need to be included in the 'linker magic'.

- - - - -

[2] Translation of "build a staticly linked Bash"

./configure --enable-net-redirections --enable-static-link \
--disable-rpath --prefix=

(Yes, that is --prefix=<whitespace>, not a typo)

make
make prefix=/opt/gnu/bash-static install-strip

- - - - -

Probably more than anyone wanted to know.
Mike
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Fri Feb 3 16:23:51 2006

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 03 Feb 2006 - 16:24:12 GMT by hypermail 2.1.8