Re: initramfs for /dev/console with udev?

[Rob Landley]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/