Quote:
Originally Posted by geekmaster
I am building aboriginal from current github source tree, for armv4l target. I see that it was just downloading musl, so I am curious (though doubtful) that it will work on my K1, considering that NiLuJe's musl test builds failed on my K1. I guess we shall see.
I suppose I need to go find OLD source that was still uClibc-based, from the landley.net download archives...
|
Why worry about the musl or the libc included with aboriginal linux as long as you don't link with those libraries? Just link with uClibc not musl. I think aboriginal gives you a choice and you should choose uClibc.
DId you get the K1 rootfs image unsquashed? Did you find the remaining files in /usr/default someplace and get those added to your K1 copy for a complete system? That should allow you to chroot into the virtual K1 and run your actual K1 programs except with the modern kernel imitating a K1 kernel. That is as far as I got.
I was going to install the header files from Amazon sources for the K1 for the 2.6.10 kernel and the headers for the uClibc into the K1 copy. Those are needed to make programs compatible with the K1. I quit at that point to do other things.
The only big problem would be to install the correct gcc into the K1 filesystem copy. Programs compatible with the K1 could then be built with the virtual K1. The gcc could then use the original K1 uclibc.so to build a dynamic executable as long as gcc is told to link with the uclibc.so and the programs include the correct headers. That should work unless there are compatibility problems between gcc versions. That potential problem could be solved by using the virtual K1 gcc to build a correct K1 gcc able to run on the K1 not just the emulator. The resulting programs should then run perfectly on the K1. I never got that far.
Having a correct build setup should make those other problems go away. I am too busy now and for the summer to ever finish so so long.