More design-work on core/gui protocol ... also tried to get hydranode binaries "shippable" with dynamic linking - I don't like the idea of having to link all the modularity together into static binary at all - if nothing else, it ruins the chances of loading additional modules. So, in order for the dynamic binaries, I need to ship all libs hydranode depends on, right? This includes libstdc++.so (837kb) and libc (1.2mb), plus few small 50-100k libs, e.g. pthread etc. Technically, when it comes to final release binary size, we don't lose much - tarball ended up being 2.2MB, compared to 1.5MB in case of static binary. Unpacked size is 6.7MB, compared to 4.2MB in case of static binary. I'd say these are reasonable sizes - I think we'r past the time where we need to count in kbytes - and if you really want to run hydranode on your handheld device ... well, we'll deal with that then. Only issue I ran into these dynamic binares was /lib/ld-linux.so.2 - what's that? That one is the only one with hard-coded path, which introduces a problem ... libc and libpthread look for GLIBC_PRIVATE in that library, and don't find it on debian woody...
Looking deeper, seems the issue raises from woody having libc-2.2.5, while nowadays we seem to have libc-2.3.2. If I could say "you need libc 2.3.2 for the binaries to work", will ppl start yelling again? Guess I have to provide full-static binaries for those people...
Anyway, all this core/gui comm work raised a lot of thoughts and ideas on what external apps / interfaces can use it ... lots and lots of ideas, heh, feels just like a year ago, when all this started :)
Madcat, ZzZz