Quote:
Originally Posted by NullNix
Well, the reason why this isn't working is simple enough -- the ELF interpreter specified by uclibc/bin/busybox is /lib/ld-uClibc.so.0. That is an absolute path, and no searching is done: the kernel just executes it directly. An ld.so in a different directory, let alone one with a different name, will never be found by this process.
But uClibc is highly reconfigurable: as noted, without the config Amazon used, it's probably best to statically link everything, so you don't depend on the God-knows-what libc config Amazon have used. If you can't get that to work, you'll never be able to get the considerably more complex dynamic linking case to work.
|
As I mentioned, I executed those incorrectly just to SEE what they were looking for. On the K1 they run correctly. New stuff I compile does not even put out those error messages, so I do not know what they are looking for. Using ELF tools is something I am not (yet) familiar with. I have *other* hobbies besides this, and fighting with build tools is not (a desirable) part of this hobby. Now if somebody were to pay me to do this, it might be much less painful; my "free" time is too valuable for this...
Regarding getting NEW custom apps running on the K1, I have done static links that work on qemu-arm-static, but not on the K1. They typically segfault or get "illegal instruction" errors (depending on which gcc version was used). The compiler flags have little effect on the results. I think either the flags are not honored in some cases, or the loader is choking on the ELF file in some cases. Not sure -- this is new territory for me (in the past I just USED the tools, and I trusted them; not so much now)...