Summary: | dev-lang/rust-1.23.0-r1 fails to build with MAKEOPTS=-l32 -> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Georgy Yakovlev <gyakovlev> |
Component: | Current packages | Assignee: | Gentoo Rust Project <rust> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | boxcars, poncho, tamiko, thomas.bettler, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/7000 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Georgy Yakovlev
2018-01-30 00:04:14 UTC
I think it fails due to MAKEOPTS change. https://github.com/gentoo/gentoo/commit/dfb3eb8a5ca1bb0fab50c6409cec7a4321b242ba I've tried building with -j16 and it didn't work, trying even less. ok I got it, it's the -l32 flag make rust build crash, not the -j32 part. this guy here extracts only -j part of the MAKEOPTS https://github.com/sakaki-/rpi3-overlay/blob/master/dev-lang/rust/rust-1.19.0-r1.ebuild building past the failure right now with MAKEOPTS="-j32", I've removed -l part. confirming successful merge without -l flag. MAKEOPTS="${MAKEOPTS} -l" does not help. checking x.py/bootstrap build -h shows this Options: -v, --verbose use verbose output (-vv for very verbose) -i, --incremental use incremental compilation --config FILE TOML configuration file for build --build BUILD build target of the stage0 compiler --host HOST host targets to build --target TARGET target targets to build --on-fail CMD command to run on failure --stage N stage to build --keep-stage N stage to keep without recompiling --src DIR path to the root of the rust checkout -j, --jobs JOBS number of jobs to run in parallel -h, --help print this help message so it does not know what to do with the -l flag, clearly it needs to be filtered out of MAKEOPTS if present. /var/tmp/portage/dev-lang/rust-1.23.0-r1/work/rustc-1.23.0-src/build/bootstrap/debug/bootstrap build --verbose --config=/var/tmp/portage/dev-lang/rust-1.23.0-r1/work/rustc-1.23.0-src/config.toml -j32 -l << here. a viable solution will be using multiprocessing.eclass ./x.py build --verbose --config="${S}"/config.toml -j$(makeopts_jobs) || die (In reply to Georgy Yakovlev from comment #5) > a viable solution will be using multiprocessing.eclass > > ./x.py build --verbose --config="${S}"/config.toml -j$(makeopts_jobs) || die Same problem here. Modifying the ebuild to inherit from multiprocessing class and performing the x.py line change does solve the error. The GitHub PR looks good to me; people with commit access should feel free to merge or rebase it. I'll get to it, but it might take a few days. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dca844ed582e369708a7769d4e84abf6e9b5fb0d commit dca844ed582e369708a7769d4e84abf6e9b5fb0d Author: Georgy Yakovlev <ya@sysdump.net> AuthorDate: 2018-01-30 04:54:54 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2018-01-31 09:56:11 +0000 dev-lang/rust: fix MAKEOPTS -l/--load-average build Upstream build system does not like -l/--load-average, So we cannot use MAKEOPTS as-is. The only relevant option is -j<num>. This commit changes to using multiprocessing.eclass makeopts_jobs() Closes: https://bugs.gentoo.org/646092 Package-Manager: Portage-2.3.19, Repoman-2.3.6 Closes: https://github.com/gentoo/gentoo/pull/7000 dev-lang/rust/rust-1.23.0-r1.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Are you sure that dca844ed582e3697 works ? Last night I got again a high load due to the build of /usr/portage/dev-lang/rust/rust-1.23.0-r1.ebuild at all 12 cores. (In reply to Toralf Förster from comment #9) > Are you sure that dca844ed582e3697 works ? > Last night I got again a high load due to the build of > /usr/portage/dev-lang/rust/rust-1.23.0-r1.ebuild at all 12 cores. it works by ignoring -l completely as it’s a limitation of upstream build system. the only option it supports is “-j” All the fix does is filtering out everything except -jX from MAKEOPTS. So you can’t really limit launching new jobs based on loadavg. Need to talk to upstream about supporting that. |