Summary: | sys-devel/gcc-11.2.1_p20211127[go] - mv: cannot stat 'cpugen.o': No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | pageexec, peter.volkov, sam, scott |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 732706, 833357 | ||
Attachments: |
build.log.xz
gcc-11.2.1_p20220115-build.log.xz gcc-11.2.1_p20220115-build.log.xz emerge --info qlist output qlop output config.log |
Description
Dennis Schridde
2021-12-06 00:02:31 UTC
Created attachment 757531 [details]
build.log.xz
i can reproduce this too. i'm no golang/automake/libtool person but it seems that there's a mismatch between what the makefiles expect as output from gccgo and what it actually produces and that's why mv fails. for example, this: /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/gccgo -B/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/cpu /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu.go /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu_amd64.go /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/internal/cpu/cpu_x86.go cpugen.go produces cpu.o and not cpugen.o that the next libtool command expects. maybe that's enough of a hint for someone to figure it out? (In reply to PaX Team from comment #2) > i can reproduce this too. i'm no golang/automake/libtool person but it seems > that there's a mismatch between what the makefiles expect as output from > gccgo and what it actually produces and that's why mv fails. for example, > this: > > /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/gccgo > -B/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/build/./gcc/ > -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem > /usr/x86_64-pc-linux-gnu/include -isystem > /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 > -g -I . -c -fgo-pkgpath=internal/cpu > /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/ > internal/cpu/cpu.go > /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/ > internal/cpu/cpu_amd64.go > /tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/libgo/go/ > internal/cpu/cpu_x86.go cpugen.go > > produces cpu.o and not cpugen.o that the next libtool command expects. maybe > that's enough of a hint for someone to figure it out? I can confirm that USE=-go allows me to build sys-devel/gcc-11.2.1_p20220115. Thanks. I don't see anything obvious at a quick glance. Reported upstream at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973. Dennis (or PaX Team), could you upload cpugen.go so I can pass it on to upstream (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973#c1)? Also, ideally a compressed version of WORKDIR? I can't yet reproduce it :( (In reply to Sam James from comment #5) > Dennis (or PaX Team), could you upload cpugen.go so I can pass it on to > upstream (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973#c1)? > > Also, ideally a compressed version of WORKDIR? > > I can't yet reproduce it :( it's a production box i saw this on but i'll try to get the stuff. i've got a gcc bugzilla account already so i can upload there directly but i think the WORKDIR archive will be rather big... suggestions to share it somehow instead of a bugzilla upload? re patches/etc, i've got nothing special here, just whatever the ebuilds do to the gcc sources. for reproduction maybe my CFLAGS can help: CFLAGS="-Wl,-z,relro,-z,now -march=znver1 -O2 -pipe -g3 -frecord-gcc-switches -fno-stack-protector -fno-var-tracking" another idea, if it's not a gcc change per se then it has to be some other package, automake or similar. did something relevant change around that time (say, last november/december)? for reference, i've got sys-devel/automake-1.16.5 (last updated on 2021.10.15) and sys-devel/libtool-2.4.6-r6 (last updated in 2019) at the moment. let me know if any other detail would help. Encountered same issue. Let me know if I can provide anything that might be useful for diagnosis in the upstream bug report. (In reply to PaX Team from comment #6) > (In reply to Sam James from comment #5) > > Dennis (or PaX Team), could you upload cpugen.go so I can pass it on to > > upstream (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973#c1)? > > > > Also, ideally a compressed version of WORKDIR? > > > > I can't yet reproduce it :( > it's a production box i saw this on but i'll try to get the stuff. i've got > a gcc bugzilla account already so i can upload there directly but i think > the WORKDIR archive will be rather big... suggestions to share it somehow > instead of a bugzilla upload? > > re patches/etc, i've got nothing special here, just whatever the ebuilds do > to the gcc sources. for reproduction maybe my CFLAGS can help: > > CFLAGS="-Wl,-z,relro,-z,now -march=znver1 -O2 -pipe -g3 > -frecord-gcc-switches -fno-stack-protector -fno-var-tracking" > > another idea, if it's not a gcc change per se then it has to be some other > package, automake or similar. did something relevant change around that time > (say, last november/december)? for reference, i've got > sys-devel/automake-1.16.5 (last updated on 2021.10.15) and > sys-devel/libtool-2.4.6-r6 (last updated in 2019) at the moment. let me know > if any other detail would help. The odd thing is, I've got everything up to date too, and I've tried in ~arch. I can try a stable chroot though with a bunch of builds. I've so far: - had other Gentoo developers try and fail in a loop - asked someone with access to a decent amount of fast machines to try a bunch of USE combinations - tried myself repeatedly in a loop - tried on machines with more cores and high -jN count for MAKEOPTS ... and got nowhere. I don't understand the upstream comment about cpugen given it seems to be the same issue for everyone in this bug, or at least related though. I'd be happy to give you scp-only access to some server to dump the files on. (In reply to Reuben Martin from comment #7) > Encountered same issue. Let me know if I can provide anything that might be > useful for diagnosis in the upstream bug report. Uploading your log & emerge --info & possibly qlop log might be useful. We want to try identify what makes your system special. Could everyone hitting this also share their config.log and full build.log (if you didn't already)? There's got to be some detail in here about why your systems are different. Also, to all of you who hit this: can you hit it *every time*? Or does it seem like a race condition? oh, and: if someone hitting it could do a build with USE=vanilla and confirm if that fails or not, that'd be helpful. Created attachment 767963 [details]
gcc-11.2.1_p20220115-build.log.xz
Here is a build.log with USE=vanilla:
* USE: abi_x86_64 amd64 cxx elibc_glibc fortran go graphite jit kernel_linux lto multilib nls nptl openmp pie sanitize ssp userland_GNU vanilla zstd
(In reply to pva from comment #11) Please include the other details I mentioned (all). Also, please use LC_MESSAGES=C. Created attachment 769289 [details]
gcc-11.2.1_p20220115-build.log.xz
Created attachment 769292 [details]
emerge --info
Created attachment 769295 [details]
qlist output
Created attachment 769298 [details]
qlop output
(In reply to Sam James from comment #12) > (In reply to pva from comment #11) > Please include the other details I mentioned (all). > > Also, please use LC_MESSAGES=C. Could you include config.log & tell me whether it happens every time or not? Or does it seem like a race condition? Created attachment 769301 [details]
config.log
I don't think this is a race condition. I've tried with -j1 and got the same result. Also if I do ebuild gcc-11.2.1_p20220115.ebuild compile it fails the same way.
Is anyone hitting this with newer versions? I still can't reproduce it. (In reply to Sam James from comment #19) > Is anyone hitting this with newer versions? I still can't reproduce it. (ideally please try 11.3.0 and/or 12.2.0) (In reply to Sam James from comment #19) > Is anyone hitting this with newer versions? I still can't reproduce it. Apparently not. |