I had been wondering for quite some time now why I had so much corruption recently. Some investigation showed that it appeared in >2gb downloads, post the 2gb margin, but reasons eluded me... until today, when I stumbled upon this little list post:
http://lists.debian.org/debian-gcc/2003/11/msg00110.htmlApparently, GCC 3.2 and 3.3 seem to have broken libstdc++ which does NOT implement 64bit file offsets. Since I initially tested large-file support using gcc 3.4, and only recently (and by accident) happened to compile/run hydranode regularly on 3.3-based system, I noticed it.
There aren't really any ways around it. It's fixed in 3.4, but it doesn't seem to be backported. And I cannot say "you need gcc 3.4 to compile hydranode" either, having gcc-3.2 required is already high enough. So, I simply had to go and rewrite all file IO code, using C functions instead. SharedFile and PartData now use new code, didn't get to update hasher code yet. And this definately broke win32 port, at least temporarely, since win32 has slightly different C function names for those calls.
*doh*.
This will introduce a delay in the release, as much as I hate to say it, since I have to start testing all over again (and I lost 15gb partial downloads due to a typo while writing the new io code - backups are for wimps :P), so ...
*doh* I'd say.
Other notes:
- It's now possible to enable/disables modules compilation with --with-MODULE / --without-MODULE configure flags. ed2k and hnsh are enabled by default. In the future, --with-MODULE=builtin syntax will be also supported.
- PIC (position-independant code) disabled for architectures where it's not needed (x86) to avoid those pesky warnings during link time (inherent from another gcc bug - wrong-code generation).
Madcat, ZzZz
