For starters, you'll have heck of a time to remove your dependency on glib.h from GTK.
You mean "remove your dependency on glib.h from libccoin", I presume? GTK has no relevance to this, besides being the administrative umbrella project for GLib.
Removing the GLib dependency is straightforward for any developer. GLib is used for a few ADTs like variable length strings, hash tables and arrays.
Both GLib and OpenSSL are heavy duty harvester combines. Removing the dependencies on them will at least halve the resource usage.
For a RedHat-ter at least make the code work with newlib instead of glib. The required knowledge should be no more than the internal phone call away for you. This includes a whole sermon on why you don't want to build a dependency on them.
Not sure you understand the problem space... First, newlib is wholly different from GLib, and does not provide the ADTs that GLib provides. Second, replacing GLib and OpenSSL would not change resource usage much at all. ADTs, Big Integer support, SHA hashing and ECDSA are required regardless of lib chosen. They would simply be replaced with... code that did the same thing under name other than "OpenSSL" or "GLib."
The performance loss for passing unions around may have been true for GCC 2.96. I'm not normally working with Linux kernel and/or GCC.
It continues to be true for all known compilers I've seen or heard of, when compared with a simple, native machine integer as used by the current implementation.
All in all, I apologise for jumping in into the battle between you and MatthewLM. Regretfully I can't easily build neither of yours code, because I'm almost exclusively working on the closed-source platforms like Windows, MacOS, etc. and standalone environments not relying on GCC/GLIB/autogen.
It will soon be building on MacOSX and Windows. Will post when this happens (volunteers willing to post building outputs are helpful). As stated, it is a developer-only release right now, so there are plenty of rough edges.
But it is a shame that another C implementation of Bitcoin is useless for the developers of Bitcoin hardware wallets.
I respectfully disagree with that assessment. Anyone looking at the code may see precisely what dependencies need replacing, for an embedded environment. If anyone actually developing hardware or embedded bitcoin solutions wishes to contact me, I would be happy to illustrate how it would work.