On Sun, 2008-11-09 at 14:44 +0800, Y. D. wrote:
> Init is probably statically linked against your C library (in this case
> glibc). Your version of init was not built against Xen friendly libc,
> hence you see this warning every time init runs.
> I have libc6-xen installed already, however, the xen friendly library
> is not statically linked by init according to your explanation. How
> should it be?
Its not going to be unless you get the source package to init and
recompile it. Your copy of init was built by your distribution and links
against a regular libc (likely, statically).
In order to change that, you will have to recompile it after installing
xen friendly libc. There is __really__ no need to do this, warnings
thrown by programs like init are completely harmless and can be ignored.
> I don't know much about this. How should libc-xen be properly used as
> an substitute of libc in face of libc's being.
libc-xen replaces most things in /lib/tls. That means, any process using
those objects is safe, which is 99.9% of everything installed by your
OS. Most programs just link dynamically, loading lib-foo.so at run time.
If, however, a program is statically linked, libc becomes a part of that
program. This means future updates to libc will make no difference to
the program, as a copy of whatever version was linked in becomes a part
of the executable itself. If you rename /lib/tls to something else ...
and the program still throws the warning .. its statically linked.
In your case, the only thing statically linked is init, which isn't
worth fussing with unless you __really__ need that warning to go away.
What I would not do is remove the warning entirely, or you will not be
alerted if you install some threading service that happens to be
statically linked with unfriendly tls.
I know its a little confusing .. but really, when talking about init ..
that warning is completely harmless.
Xen-users mailing list