Summary: | sys-devel/gcc-10.1.0-r1: gcc/xgcc: No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Levine <plevine457> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | poncho, yurikoles |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://gcc.gnu.org/PR96160 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log.bz2
emerge --info gcc-10.1.0-xgcc-selftest-makeopts.patch |
Created attachment 644760 [details]
build.log.bz2
Created attachment 644762 [details]
emerge --info
Created attachment 644764 [details, diff]
gcc-10.1.0-xgcc-selftest-makeopts.patch
I'm not sure if this is the right way to deal with it, but if xgcc is supposed to be built before the selftest target, it seems straightforward to just add it to the recipe.
Yeah, this race keeps popping up occasionally. Can you send the patch upstream to see if it's a correct fix? Had the same issue while updating to sys-devel/gcc-9.3.0-r1 Reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96160 Can anyone reproduce this with FEATURES=-ccache? (In reply to Peter Levine from comment #7) > Can anyone reproduce this with FEATURES=-ccache? Yes, I'm not using ccache (In reply to poncho from comment #8) > (In reply to Peter Levine from comment #7) > > Can anyone reproduce this with FEATURES=-ccache? > > Yes, I'm not using ccache Could you attach the build.log. (In reply to Peter Levine from comment #9) > Could you attach the build.log. Unfortunately not. I don't have yesterday's log anymore and recompiling today works without an issue. (In reply to poncho from comment #10) > (In reply to Peter Levine from comment #9) > > Could you attach the build.log. > > Unfortunately not. I don't have yesterday's log anymore and recompiling > today works without an issue. OK. It's just that builroot project seems to describe the exact issue as a ccache related issue at https://github.com/buildroot/buildroot/commit/51c2080c7bcdf995e492d6dc03c5a41c57825f5a. That would make sense since the command that triggers the bug on my end is > var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/testsuite/selftests There're are a few places with /dev/null in it. That doesn't make any sense as a gcc make target. I would think that might be related to a ccache or sandbox issue. If so, my patch would just be a workaround. I hit the bug on my Raspi for gcc-9.2.0-r1. I did not any fancy stuff with ccache and the like... I have saved /var/tmp/portage/sys-devel/gcc-9.3.0-r1 - which I can upload either fully or in part. If someone out there bothers about it. I tried to implement the patch from Peter Levine - but I did not see it applied. It is my first EAPI 7 ebuild. OK, but back to topic: the following ebuild did succeed - but if have the remnants of the failed ebuild. Upstream issue is fixed. Let's declare it resolved for gcc-11 and above. |
Building sys-devel/gcc-10.1.0-r1 with multiple jobs in MAKEOPTS results in: > /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/testsuite/selftests > /bin/bash: /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc: No such file or directory > make[3]: *** [/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 127 > make[3]: *** Waiting for unfinished jobs....