I want to replace init with my own little init hack, then call the original init. Barring that, I'd be satisfied being able to replace player, instead (again, running my own hack then calling the original player).

Right now, I have a hack that just does an execv of the original (init or player, whichever I'm replacing). Unfortunately, this is failing. If I rename init -> init.original, then put my init in place, the Rio hangs.

#include <unistd.h>
int main (int argc, char *argv[]) {
execv("/sbin/init.original", argv);
}

I built this replacement init using Jeff Mock's toolchain. I've built and tested other simple hacks using his toolchain, and installed them into his handily packaged developer filesystem, and they run, so I'm pretty sure the executables are "good". However, for my "live" tests, I'm working on a pristine receiver.arf in which I've simply moved init -> init.original and put my init in /sbin.

Am I using execv incorrectly? Is there something in the "pristine" receiver.arf that's incompatible with binaries built using Jeff's toolchain? Some unknown dependancy? If I can help it, I really don't want to build a kernel yet

All I -really- want to do is get my VNC server daemon up and running so I don't need Java to run the danged thing remotely And so I can add keyboard controls instead of having to mouse around.

Nevermind. I took a look at Frank's receiver.arf patch and noticed what I was doing wrong with the bash approach (which I -did-, in fact, try before I went about hacking up a C tool ). I've now got myself a proper "init", so I'll get back to hacking on the VNC server now.

Try adding -static to the gcc options when you link.

The binary will be huge, but it should work.