| ^~~~~~~~ src/utils/lib/CryptoPP.cc: In function ‘unsigned int CryptoPP::DERLengthEncode(CryptoPP::BufferedTransformation&, unsigned int)’: src/utils/lib/CryptoPP.cc:7379:24: error: reference to ‘byte’ is ambiguous 7379 | bt.Put(byte(length)); | ^~~~ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/stl_algobase.h:61, from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/memory:63, ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1-j2-20210510-164358 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-11.1.0 * clang version 12.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/12/bin /usr/lib/llvm/12 12.0.0 Python 3.8.10 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-bin-1.52.1 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.292_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Fri May 14 04:50:23 UTC 2021 emerge -qpvO net-p2p/mldonkey [ebuild N ] net-p2p/mldonkey-3.1.7-r2 USE="ocamlopt -bittorrent -doc -fasttrack -gd -gnutella -gtk -guionly -magic -upnp"
Created attachment 708285 [details] emerge-info.txt
Created attachment 708288 [details] emerge-history.txt
Created attachment 708291 [details] environment
Created attachment 708294 [details] etc.portage.tar.bz2
Created attachment 708297 [details] logs.tar.bz2
Created attachment 708300 [details] net-p2p:mldonkey-3.1.7-r2:20210514-060456.log
Created attachment 708303 [details] temp.tar.bz2
Is this bundling crypto++?
It still compiles correctly for me with sys-devel/gcc:10. I think the issue is only triggered with sys-devel/gcc:11, which is still in ~arch. There seems to be an upstream patch for it: https://github.com/ygrek/mldonkey/commit/d9394aa I'm currently merging sys-devel/gcc:11 to try to reproduce the issue and test the patch. Answering Sam's question and looking at the comments inside CryptoPP.cc, yes, this seems to be a modified copy of crypto++: > // This file contains a subset of the Crypto++ library (version 5.2.1), with > // kind permission from Wei Dai. Please note that this file should not reflect > // on the real Crypto++ library in any way, as this file been greatly mangled to > // reduce the code-size, since this app only makes use of RSA classes (for Secure > // Identification) and the MD4 hashing class (for FileIDs). I don't know how easy (if possible) unbundling it could be without modifying the code. Looking at the Makefile, it seems this is used by DonkeySUI and could be avoided with --disable-donkeysui (with the obvious side effect of disabling SecureUserIdent for the eDonkey protocol). I think the easiest and fastest solution is testing the upstream patch.
The upstream patch doesn't fix it for me. This will need more research.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=207859482e3cca4d24bbb1d96e7a0f3511725d38 commit 207859482e3cca4d24bbb1d96e7a0f3511725d38 Author: Jesus P Rey (Chuso) <gentoo@chuso.net> AuthorDate: 2021-07-15 18:56:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-07-16 01:33:18 +0000 net-p2p/mldonkey: Patch for C++17 support. Signed-off-by: Jesus P Rey <gentoo@chuso.net> Closes: https://bugs.gentoo.org/790134 Closes: https://github.com/gentoo/gentoo/pull/21663 Signed-off-by: Sam James <sam@gentoo.org> net-p2p/mldonkey/files/cpp17-byte-namespace.patch | 63 +++++++++++++++++++++++ net-p2p/mldonkey/mldonkey-3.1.7-r2.ebuild | 2 + 2 files changed, 65 insertions(+)
