ELKS disk images updated
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Alan Carvalho de Assis
Do you think it is possible to port busybox (and uClibc) to 8086?
We don't require uClibc, since the 8086 libc that comes with Dev86 is probably even smaller. 32+-bit centric C libraries are extremely unlikely to play nicely with ELKS; consider that the libc.so for a typical i386 uClibc is hundreds of KiB, which is way too fat for ELKS. The biggest problem with porting any software to ELKS is that the final binary's .text segment absolutely must be less than 64 KiB in size, with the secondary problem being that ELKS doesn't support many of the modern libraries and interfaces that are used by other projects.
BusyBox would be FANTASTIC to port to ELKS, and you're correct that it would drastically shrink the size of the binaries. Unfortunately, BusyBox is also massive by ELKS standards. Note that ELKS "ls" has no help text and is lacking many features; other binaries are the same. Everything we currently use is a heavily stripped down version often derived from code that is well over 10 years old, plus we are restricted to a dialect of C that will no doubt require some extra rewriting to conform to. I feel that a much better approach will be to take the separate sources we have now and combine them into an ELKS "BusyBox" instead. It would involve far less work since the tools work fine with ELKS already and are written in the C dialect required. I'll take another look and see what I could do to merge them together.
Quoted 2 lines
I noticed which summing up just the binaries bigger than 8000 bytes it is more than 300KB :
sh is a copy of ash, not a symlink, unless you use the 360K root disk, where I symlinked it and was able to copy a few more useful tools such as "tr" because of the extra 50K I gained. I will correct that problem later; the other disks had free space whereas the 360K root disk was totally full. When I built new binaries with the latest Dev86 toolchain, all binaries shrunk, so I took advantage of this to further reduce the size of the system. The 360K disk is still completely full...but now it has more stuff! :-)
Jody Bruchon
On 2/19/12, Jody Bruchon <[email protected]> wrote:
snip
Quoted 5 lines
I feel that a much better approach will be to take the separate sources we have now and combine them into an ELKS "BusyBox" instead. It would involve far less work since the tools work fine with ELKS already and are written in the C dialect required. I'll take another look and see what I could do to merge them together.
Yes, you are right, modifying existent programs source code to become just a single binary like busybox will be easier than porting original busybox to ELKS.
Do you think it is easy to port Linux applications to use Dev86 libc or is it very inconsistent?
Quoted 9 lines
sh is a copy of ash, not a symlink, unless you use the 360K root disk, where I symlinked it and was able to copy a few more useful tools such as "tr" because of the extra 50K I gained. I will correct that problem later; the other disks had free space whereas the 360K root disk was totally full. When I built new binaries with the latest Dev86 toolchain, all binaries shrunk, so I took advantage of this to further reduce the size of the system. The 360K disk is still completely full...but now it has more stuff! :-)
I noticed some commands are not working correctly, please try this one:
# cd /bin # ls -l | more
I think the problem is on pipe (|) because "more file" is working.
Thank you very much!
Best Regards,
Alan