From: BlaisorBlade <blaisorblade_spam@yahoo.it>
To: user-mode-linux-user@lists.sourceforge.net,
Jeremy Utley <jerutley@gmail.com>
Cc: user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] Re: [uml-user] Re: 2.6.9 guest - no make linux target
Date: Tue, 26 Oct 2004 13:31:04 +0200 [thread overview]
Message-ID: <200410261331.04030.blaisorblade_spam@yahoo.it> (raw)
In-Reply-To: <d5d4185b041025220324d20c9e@mail.gmail.com>
On Tuesday 26 October 2004 07:03, Jeremy Utley wrote:
> On Tue, 26 Oct 2004 02:31:59 +0200, BlaisorBlade
>
> <blaisorblade_spam@yahoo.it> wrote:
> > On Tuesday 26 October 2004 02:30, Sven Köhler wrote:
> > > >>This looks like a problem i had too! It was caused by
> > > >> compiling/running the kernel on a NPTL-enabled system. So i
> > > >> downgraded to a
> > > >>non-NPTL-glibc, and everything worked fine again.
> > > >
> > > > It would work also on a NPTL glibc, but it must be setup as in
> > > > mainstream distros - i.e. a non-NPTL glibc in /lib and the NPTL one
> > > > elsewhere, i.e. in /lib/tls. Otherwise, UML is linked against the
> > > > NPTL glibc and does not work.
> Which would mean that no binaries compiled on that system will be
> linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO,
> this still needs to be resolved in some way.
No, this is (slightly) false. Or better, I've read directly the document on
LD_ASSUME_KERNEL on Ulrich Drepper's homepage
(http://people.redhat.com/drepper/). The doc is at:
http://people.redhat.com/drepper/assumekernel.html
What happens on RedHat/FedoraCore:
- ld-linux.so.2 searches first /lib/tls, then /lib/i686, then /lib (which is
like modifying LD_LIBRARY_PATH, but hardcoded in the linker).
This is done to match the LD_ASSUME_KERNEL orderings - ld-linux.so will load a
library only if its ABI tag (which is stored inside the library and can be
read with eu-readelf --notes) is not stricter than the running kernel. The
linker does not search for the stricter requirements, so the search path must
be the above one.
$ eu-readelf --notes /lib/tls/libc.so.6
Note segment of 32 bytes at offset 0x00000154:
Owner Data size Type
GNU 16 VERSION
OS: Linux, ABI: 2.4.25
$ eu-readelf --notes /lib//libc.so.6
Note segment of 32 bytes at offset 0x00000134:
Owner Data size Type
GNU 16 VERSION
OS: Linux, ABI: 2.2.5
$ eu-readelf --notes /lib/i686/libc.so.6
Note segment of 32 bytes at offset 0x00000134:
Owner Data size Type
GNU 16 VERSION
OS: Linux, ABI: 2.4.1
> > > So UML will not run on NPTL-enabled gentoo-systems, since
> > > gentoo-ebuilds won't build two glibcs (actually they will in the
> > > future, but those ebuilds aren't stable yet).
> > Ah, so that is the only problem? And "not stable" means that it is
> > "~x86" (almost perfect) or "-*" (dangerous)? I'll check by myself anyway.
> > > Will the right libc.so
> > > from /lib be loaded instead of the one from /lib/tls?
No, the /lib/tls one should get loaded, but in that case it seems to work.
Actually, I've never heard that UML has (unfixed) bugs when linked to NPTL.
Apart from link failures on recent glibc/toolchains :-(, which is not your
case.
> > On my MDK it works quite fine. And it has glibc2.3.3 (actually this is
> > meaningless, since distros anyway must use snapshots).
> MDK's glibc, even in 10.0, is NOT using NPTL - it's still using
> linuxthreads - to see, run the /lib/libc.so.6 from a shell prompt, and
> see the output - you'll note there's no mention of NPTL.
You still refuse to take a look at my point. Look at the /lib/tls one, which
is NPTL-enabled. Neither RH/FC nor Mandrake, nor I guess SuSE, put a NPTL
enabled glibc in /lib. /lib/tls is the right location.
The only current distro without NPTL support, for what I know, is Slackware
10.0.
$ /lib/libc.so.6
[...]
Compiled by GNU CC version 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk).
Compiled on a Linux 2.6.0 system on 2004-02-16.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
$ /lib/tls/libc.so.6
[...]
Compiled by GNU CC version 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk).
Compiled on a Linux 2.6.0 system on 2004-02-16.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
(Are you noticing this?)
NPTL 0.60 by Ulrich Drepper
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
> What needs to happen is for someone VERY familiar with the UML code to
> dig in, and find out why the binutils assertion failure keeps tripping
> up. That's the only error that currently comes about, and it causes
> any UML kernel to segfault immediately upon execution. I have straces
> available of the linux binary showing where it segfaults.
I can get the assertion failure on FC2 - 64bit. I think I could run the
binary, but I would not be surprised that I forgot to actually make sure of
that.
The first thing I'm trying to do is to add "executable_start" as in the
default ld linker scripts. When it will work, I'll let you know.
Bye
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
parent reply other threads:[~2004-10-26 11:30 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <d5d4185b041025220324d20c9e@mail.gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200410261331.04030.blaisorblade_spam@yahoo.it \
--to=blaisorblade_spam@yahoo.it \
--cc=jerutley@gmail.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=user-mode-linux-user@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).