Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary
irc.hydranode.com/#hydranode

Wednesday, May 11, 2005

Dynamic release binaries ?

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



Comments:
As far as I know you can do workaround with:
(example)
./ld-2.2.5.so --library-path ./PATH ./hydranode.bin

It worked fine for me for other dynamic binary.
 
about core/gui comm work, you could break the standard way of doing things and make 3 types of gui protocols or behaviors: remote internet, remote lan and localhost

BTW will there be a web gui? will it support pipelining and gzip? will it required a full webserver?

p.s. is import support implemented already? if yes then which clients are supported?
 
"about core/gui comm work, you could break the standard way of doing things and make 3 types of gui protocols or behaviors: remote internet, remote lan and localhost"
Why triple the work?

"BTW will there be a web gui? will it support pipelining and gzip? will it required a full webserver?"
Yes, there will be a web-gui, got several cool features in mind that aren't usually found on web/webinterfaces. Gzip - yes, pipelinig - we'll see. And most likely it'll include a webserver in itself, since requiring users to install/configure apache isn't a good idea.

p.s. is import support implemented already? if yes then which clients are supported?
Not yet, but it's been planned for quite some time now. Ideally, I'd like to keep the original files in sync with our own formats, so it needs bit more work than simply importing - we also want to update the original files as we download more, in order to allow switching back and forth between hydranode and other clients.

Madcat.
 
What about windows? will all those boost DLLs be included, and will you include the CRT DLLs (msvcr71.dll/msvcp71.dll)? (if you link to the old VC6 CRT DLL, msvcrt.dll, you dont have to distribute it cos it comes with windows)
 
MSVC6 cannot compile hydranode, thus I need to compile it with MSVC7.1, and thus distribute msvcp71.dll. And yes, boost dlls will be included - they are very small, 20-50k each.

Madcat.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?