Exactly correct, Tomatoware binaries are hard coded with Tomatoware's version of libc (uclibc). Here is a selection that used to be in the README, but I took out. (Maybe I should put it back in). There were too many problems trying to create a system that would build against the tomato libraries. Even more problematic, Tomato's libraries are pretty minimal. Need libssp? You won't find it in Tomato. (This actually caused some issues with compiling dnscrypt, to which the author so kindly removed its mandatory dependency on libspp, and made it optional). Getting a semi-modern compiler to work was going to be a no go as well. Tomato actually runs on some older technology. Not saying it's bad in the least bit, but moving to newer stuff is more work than it's worth (and probably impossible too because of binary blobs we have to work with). The choice was clear to me that using tomato's libraries was not a possibility. Because of this, binaries produced by tomatoware do not use the system's built in libraries, rather, the supplied libraries that come with tomatoware. If you did managed to hard code any binaries you produced with tomatoware to the system libs (possible through some LDFLAGS commands), the results would be unpredictable. Tomato's version of uclibc is older than tomatoware, and uclibc does not guarantee any kind of compatibility from release to release. My answer to binary portability has always been to compile static binaries. All the libraries in Tomatoware are available in their static (and dynamic) forms to allow for this. edit: If size is going to be restraining issue, you can strip and then compress the binary (with upx). I do this for all binaries I publish. This usually does pretty well.