From: Rob Landley <rob@landley.net>
To: Roland Dreier <rolandd@cisco.com>
Cc: Robert Schwebel <r.schwebel@pengutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: initramfs for /dev/console with udev?
Date: Thu, 3 Nov 2005 15:29:59 -0600 [thread overview]
Message-ID: <200511031529.59529.rob@landley.net> (raw)
In-Reply-To: <52mzkl4i8y.fsf@cisco.com>
On Thursday 03 November 2005 13:57, Roland Dreier wrote:
> > On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
> > > [...] klibc didn't compile for ARCH=um.
> >
> > I repeat my question: what is it that didn't compile, klibc or the
> > kernel?
>
> come on, dude -- how much clearer can he be?
Ah, I see. The linux kernel headers you feed it were from a kernel compiled
with ARCH=um. Right. It's been a while since I tried feeding any libc
actual kernel headers. (I build uClibc against the cleaned up userspace ones
here: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ .)
It's also been a while since I played with klibc, and I notice that it doesn't
work with Maszur's headers. (It sort of works, with lots of warnings, until
about halfway through when it wants to touch "asm/signal.h", when Maszur's
just has linux/signal.h, and symlinking the two still isn't happy because
sigset_t is never defined... In klibc there's definitions for ia64, sparc,
and parisc. But nothing for x86...
Ok, checking 2.6.14/include/asm-i386 it's an unsigned long, so typedef that...
Nope, still not happy, wants numerous other symbols now... Okay, try
grabbing asm-i386/signal.h from libc... And asm-generic/signal.h which
_that_ includes... And now there's a "previous declaration of 'wait3"'
conflicting. Beautiful...)
Ok, I remember why I stopped playing with klibc now. It's still deep in
alpha-test stage, requires way more incestuous knowledge of the kernel
headers than anything not bundled with the kernel itself has any excuse for,
and I'm still not sure what advantage it claims to have over uClibc except
for being BSD licensed.
If you have to make it work, I'd suggest extracting a fresh kernel tarball, do
"make allyesconfig" (without ARCH=um), and use _those_ headers. Or just
accept that it doesn't work and try uClibc. :)
Rob
next prev parent reply other threads:[~2005-11-03 21:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-02 22:20 initramfs for /dev/console with udev? Robert Schwebel
2005-11-03 3:40 ` Rob Landley
2005-11-03 6:47 ` Robert Schwebel
2005-11-03 17:38 ` Rob Landley
2005-11-03 18:51 ` Robert Schwebel
2005-11-03 19:13 ` Rob Landley
2005-11-03 19:57 ` Roland Dreier
2005-11-03 21:00 ` Rob Landley
2005-11-03 21:29 ` Rob Landley [this message]
2005-11-04 21:39 ` Martin Schlemmer
2005-11-04 23:10 ` Rob Landley
2005-11-04 23:11 ` Rob Landley
2005-11-05 0:26 ` Martin Schlemmer
2005-11-05 2:56 ` Rob Landley
2005-11-03 21:41 ` Rob Landley
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=200511031529.59529.rob@landley.net \
--to=rob@landley.net \
--cc=linux-kernel@vger.kernel.org \
--cc=r.schwebel@pengutronix.de \
--cc=rolandd@cisco.com \
/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