MobileRead Forums - View Single Post

geekmaster · 05-13-2016, 02:01 AM

It seems like PURE static is the only thing safe for a K1, until we can get a compatible (i.e. IDENTICAL) uclibc set of tools that exactly match the uclibc used in the K1 (based on claims at uclibc.org that config changes to uclibc can require recompiling ALL binaries that use it).

Regarding small libc libraries (whilst I prefer bare metal -- talking direct to I/O ports), I have stumbled across this more than once over the years, and I think it kinda cool:
http://www.muppetlabs.com/~breadbox/software/tiny/
http://www.muppetlabs.com/~breadbox/...ny/useful.html

The bulk of my original windows programs do direct winapi calls, and avoid libraries whenever possible. I have more control that way, and I feel more comfortable closer to the bare metal where library mismatches are unlikely to occur, so those tiny direct API call programs at the link above fascinate me. That seems most likely to work on the K1 -- I should try building some that way (with suitable arm instructions, of course), and the asm could call C as well, so just an asm wrapper around C would be my goal -- no libc needed. The difficulty will be figuring out the linkage needed for kernel modules (and they should be even easier, perhaps)...

Or this for bare-metal arm apps:
https://balau82.wordpress.com/2010/0...ogram-for-arm/

In linux, everything is a file, so this:
https://en.wikipedia.org/wiki/Write_..._calling_write
Yeah, that's is in my bare-metal ballpark, for sure. If I can write to the framebuffer and read input events, it's all cool...

If I do not USE any libc (or other) library (i.e. as bare-metal as I can get), how can the code fail on a K1? Well, unless everything I have learned about the K1 is a lie, of course. Not sure about anything anymore... Need some sleep...

But if I must stick with a library, then perhaps musl is the (or a) way to go...

05-13-2016, 02:01 AM	#149
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773670 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	It seems like PURE static is the only thing safe for a K1, until we can get a compatible (i.e. IDENTICAL) uclibc set of tools that exactly match the uclibc used in the K1 (based on claims at uclibc.org that config changes to uclibc can require recompiling ALL binaries that use it). Regarding small libc libraries (whilst I prefer bare metal -- talking direct to I/O ports), I have stumbled across this more than once over the years, and I think it kinda cool: http://www.muppetlabs.com/~breadbox/software/tiny/ http://www.muppetlabs.com/~breadbox/...ny/useful.html The bulk of my original windows programs do direct winapi calls, and avoid libraries whenever possible. I have more control that way, and I feel more comfortable closer to the bare metal where library mismatches are unlikely to occur, so those tiny direct API call programs at the link above fascinate me. That seems most likely to work on the K1 -- I should try building some that way (with suitable arm instructions, of course), and the asm could call C as well, so just an asm wrapper around C would be my goal -- no libc needed. The difficulty will be figuring out the linkage needed for kernel modules (and they should be even easier, perhaps)... Or this for bare-metal arm apps: https://balau82.wordpress.com/2010/0...ogram-for-arm/ In linux, everything is a file, so this: https://en.wikipedia.org/wiki/Write_..._calling_write Yeah, that's is in my bare-metal ballpark, for sure. If I can write to the framebuffer and read input events, it's all cool... If I do not USE any libc (or other) library (i.e. as bare-metal as I can get), how can the code fail on a K1? Well, unless everything I have learned about the K1 is a lie, of course. Not sure about anything anymore... Need some sleep... But if I must stick with a library, then perhaps musl is the (or a) way to go... Last edited by geekmaster; 05-13-2016 at 02:57 AM.