[BusyBox] Re: busybox and libc5

Simon Byrnand sbyrnand at xtra.co.nz
Thu Jun 22 19:59:22 UTC 2000


At 08:36 AM 22/06/00 -0600, you wrote:

>> This is a stock Slackware 3.4 install with all the devel tools installed,
>> but with the kernel and kernel sources updated to 2.0.38.
>
>Ok.  I see.  /usr/include/asm is provided by the kernel.  So while I have the
>libc5 port complete, it looks like some work is needed to make BusyBox work
>with the 2.0.x kernels.  Do you have the skill to fix this?  If so I would
>welcome a patch.  If not I will add "Make BusyBox work with Linux 2.0.x" into
>the TODO list.

Hmm,

Not really, but I'll have a fiddle anyway. :)

I seem to remember reading somewhere that one of the "problems" with libc5
was that the app you're compiling had to use some of the kernel-provided
header files when it wasnt really neccessary, which would make compiling
somewhat dependant on the kernel version - even if there was no dependancy
on the change in kernel version for the c features actually used by the
compiled program.

In other words, if you compiled it for libc5 but on a system running a 2.2
kernel, the resulting executable would probably run ok on a 2.0 kernel
system - even though it wont actually *compile* on a 2.0 kernel system
because of the difference in kernel header files. I'd be interested to test
that theory actually - do you think you could compile a copy of busybox
with your libc5 compatibility libs and send it to me to see if it runs? Or
if you have a 2.0 machine handy somewhere, try running the resulting binary
and see if it actually works.

Assuming it does the changes required for 2.0 arent anything to do with the
actual kernel differences per se, but rather only to do with differences in
header files. Where to go from there I'm not sure - I've run into this
problem before with other programs - either some required header files are
actually missing altogether, or the 2.0 version of the header files have
some declarations missing, or even have some extra declarations which are
already defined somewhere else, and sometimes defined differently :(

And that is about the limit of my knowledge about the issues of header file
differences...I think this exact problem was one of the driving forces
behind glibc2 - it was supposed to isolate the kernel and kernel headers
from "typical" applications which dont need to know internal kernel
structures - it provides somewhat duplicated header files seperate to the
kernel header files that document the external features of the kernel and
stop compiling of normal applications from being so kernel dependant, or at
least reduce it to a minimum...is that correct ?

>I'm cc'ing the busybox mailing list with this.  I hope you don't mind.

Sure. Hopefully theres someone out there that has experience in backporting
stuff to 2.0 and fixing up all this mess with headers which seems to plauge
such attempts. (Busybox is by no means an exception :)

Regards,
Simon








More information about the busybox mailing list