FWIW, I am against bundling a patched version of cryptopp

I totally agree with that.

I don't really know why bundling a copy of crypto++ looked like a good idea. I know the situation may be different in other OS's (mostly, Windows), but Linux and other systems usually have a current version of crypto++ available that MLDonkey could be linked against.

Bundling its own copy of crypto++ would lead to falling behind upstream until issues starting to appear due to outdated unmaintained code. Which is exactly what is happening. This bundled crypto++ has been untouched for 7 years. And it's then when issues start appearing.

and carrying a non-trivial patch as that.

You mean my patch is non-trivial?
It's just a change in less than ten lines to move a variable to a new namespace, which is exactly the same change done upstream after long discussion and testing.

It is better to upgrade and sync with upstream, instead of patching the old version. My 2 cents.

That's basically what this PR is doing by applying the same patch that was applied upstream to fix #62.
What #63 does instead is sticking compilation to C++14 to avoid the issue without fixing it.

I would rather remove this bundled crypto++ version and link against the system's one, but that doesn't look like an easy change.

#62 doesn't do much more than just testing if the compiler takes "-std=c++14", and prepend if it does. If it does not work with gentoo, you proably want to check that you are starting from clean mldonkey. In particular, you need to do 'make distclean' or some such to remove the generated "config/configure", for it to be re-generated, if you have already started ./configure and building and encountered the error.

No, I haven't already run ./configure and started the build process. The build process is automated in Gentoo and that's not how it works.

Anyway, I don't think it's worth discussing whether #63 works or not for keeping compilation at C++14 to avoid an issue that can be fixed instead the same way that was fixed upstream.

Hi

please, can you remove the #include <caml/config.h> in the src/utils/lib/CryptoPP.h file ? this can resolve #86 when apply this PR

greetings

the proper way forward would be to upgrade bundled cryptopp (or better yet unbundle), but i don't have capacity for this now
this patch makes sense and will be naturally dropped when cryptopp is upgraded

CI on macos is still not nappy - https://github.com/ygrek/mldonkey/actions/runs/10138536812/job/28030381201#step:9:2133
the reason apparently is autoconf doing too much o_O

merging anyway