^^^^^ Warning 67 [unused-functor-parameter]: unused functor parameter Proto. /usr/bin/ocamlopt.opt -inline 10 -w +a-3-4-6-27-29-32-35-37-41-44-45-48-60-70 -I src/utils/extlib -I src/utils/cdk -I src/utils/bitstring -I src/utils/lib -I src/utils/ocamlrss -I src/utils/xml-light -I src/utils/net -I tools -I src/daemon/common -I src/daemon/driver -I src/utils/mp3tagui -I src/config/unix -I src/networks/direct_connect -I src/networks/fileTP -I src/networks/donkey -I +camlp4 -c src/networks/donkey/donkeyOvernet.ml File "src/networks/donkey/donkeyOvernet.ml", line 2081, characters 6-26: 2081 | DonkeyNodesDat.parse filename bootstrap ^^^^^^^^^^^^^^^^^^^^ Error: Unbound module DonkeyNodesDat make: *** [Makefile:5440: src/networks/donkey/donkeyOvernet.cmx] Error 2 shuffle=1192069123 * ERROR: net-p2p/mldonkey-3.2.1::gentoo failed (compile phase): ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_gnome_systemd-20241007-040514 UNMASKED: /etc/portage/package.unmask/60gcc:<sys-devel/gcc-15.0.9999:15 Requested by sam Issues involving opaque types / incomplete typedefs should block bug 930805 /etc/portage/package.unmask/50unstable:>=sys-libs/ncurses-6.5 Block bug #351559 if this looks like a parallel build issue. Possible reproducer: MAKEOPTS='... shuffle=1192069123' The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- GNUMAKEFLAGS="$GNUMAKEFLAGS --shuffle" gcc-config -l: [1] x86_64-pc-linux-gnu-15 * clang/llvm (if any): clang version 19.1.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/19/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/19 19.1.1 Python 3.12.7 Available Ruby profiles: [1] ruby32 (with Rubygems) [2] ruby33 (with Rubygems) * Available Rust versions: [1] rust-bin-1.81.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 17.0.12_p7 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.4_p7 [openjdk-bin-21] 3) Eclipse Temurin JDK 8.422_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-17 [3] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.23.1 linux/amd64 HEAD of ::gentoo commit 2a58c05451fee793641ddd2dd4eea20256f139ac Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Oct 13 09:48:36 2024 +0000 2024-10-13 09:48:35 UTC emerge -qpvO =net-p2p/mldonkey-3.2.1 [ebuild N ] net-p2p/mldonkey-3.2.1 USE="magic ocamlopt -bittorrent -doc -fasttrack -gd -gnutella -upnp"
Created attachment 905613 [details] emerge-info.txt
Created attachment 905614 [details] emerge-history.txt
Created attachment 905615 [details] environment
Created attachment 905616 [details] etc.clang.tar.xz
Created attachment 905617 [details] etc.portage.tar.xz
Created attachment 905618 [details] logs.tar.xz
Created attachment 905619 [details] net-p2p:mldonkey-3.2.1:20241013-112058.log
Created attachment 905620 [details] qlist-info.txt.xz
Created attachment 905621 [details] temp.tar.xz
Created attachment 906617 [details] build.log I updated to GCC 15 and even tried the same USE flags for net-p2p/mldonkey but I am not able to reproduce this issue. The issue is probably not even related to GCC as this is an OCaml project compiled by the OCaml compiler (apart from a few C/C++ files, but in this case it's failing while compiling an OCaml file). The "unbound module" error in the log is typically caused by parallel builds because there are dependencies in the order source files are compiled so this package doesn't support parallel builds. See bug 582136 and upstream issue 48[1]. That's why -j1 is hardcoded in the ebuild to force non-parallel builds. But it seems your build somehow is still forcing parallel builds. As you can see from my log, the donkeyNodesDat file is compiled before donkeyOvernet where you get the unbound module error. The whole compilation order looks different in your case, which shouldn't happen and it's a known cause for issues because, as mentioned, there are dependencies in the order files are compiled. I even tried the same dev-build/make version up to the revision to check if maybe a different make version causes "-j4 -j1" to be interpreted differently (even when we only differed in the ebuild revision), but with the same exact dev-build/make, for me it still results in parallel builds to be disabled as required by this project and the source files to be compiled in the same order. [1] https://github.com/ygrek/mldonkey/issues/48
