I am trying to develop an application to run on an embedded linux installation. It comes with an older version of libc than I have on my development maching. If I were to create a chroot environment on my development machine, copy the libraries from my embedded device in such a way that the chroot environment mirrors the device and then build the application, would it be safe to run on the device? My dev machine and the device are both x86 32 bit so I don't think I need to cross compile.
Also should the application I write require linking to additional libraries (that are not present on the device) am I safe to build these libs on the dev machine in the chroot and then just copy them to the device for application deployment?
From all the reading I have done on this subject it appears that the only way I can ensure that everything links together properly would be to actually build the application on the device but this is not an option as it is a minimal install and doesn't come with gcc installation.
Best Answer
This will generally work. I would just give it a try, but there are a few things you need to be aware of:
When building, binaries need to be built for the CPU architecture and capabilities of your target. Given that they're both x86, this will help a lot, but you still need to be careful about using processor features like sse3, etc. If you build a binary that takes advantage of features that are absent on your target installation, it won't work.
Your build system's kernel might exert some influence over the behaviour of your chrooted environment. You can't use a different kernel for a chroot vs the host system, so you may encounter discrepancies between the two. Apps generally ultimately communicate with the kernel via libc though, which provides a standard interface that can help prevent such problems.
Your libc needs to be compatible with your kernel, to some degree. The libc from your embedded system might not be totally compatible with your kernel, depending on interface changes; however, if the libc predates your kernel, this is unlikely to be a problem (old kernel interfaces are more likely to stick around to support old binaries).
Your host system's services will be visible to your embedded system. This is common to any chroot, as they share process tables, network interfaces, etc.
For your 'additional libraries', you could use static linking to link those to your application. Then you can avoid deploying the libraries to the device. Your mileage may vary.
You might consider using a virtual machine to do this instead. It won't necessarily remove all the concerns (like processor features/flags), but you can have an environment that matches your embedded system much more closely. That is, you can use the same kernel, run the same boot process, avoid contamination by the host's services...
Be aware that if you set up a build toolchain inside your chroot, you might want to think about how you will copy the new files back to your embedded system; you probably do not want to copy the toolchain files (gcc, etc).
Try setting it up and writing a test application, build some libraries or whatever, and see how well they work when moved to the embedded system.