| Summary: | sys-devel/gcc-8.2 Link tests called after GCC_NO_EXECUTABLES resulting in stage 1 build failure | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ephemer0l <om> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | gmt, jstein, slyfox |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build log | ||
|
Description
ephemer0l
2018-08-23 01:43:58 UTC
Created attachment 544598 [details]
build log
This "smells" parallel-build related. What happens if you turn right around after this error and invoke: ebuild $(portageq envvar PORTDIR)/sys-devel/gcc/gcc-8.2.0-r2.ebuild compile ? To be clear, not dismissing your problem, as a parallel-build issue is still an issue, as obviously toolchain ebuilds ought to be (and usually are) as robust as possible in the face of MAKEOPTS="-j$((RANDOM/128))". 1. Can you also attach 'emerge --info gcc' if that system? 2. Also, gcc ebuild package all relevant build logs and asks to attach those as well. Can you do that? Namely it says: """* Please include /var/tmp/portage/sys-devel/gcc-8.2.0-r2/work/gcc-build-logs.tar.bz2 in your bug report.""" 3. Is build failure reproducible? Closing after a timeout. Feel free to file a new bug with some details if it happens again. gcc-build-logs.tar.bz2 would be most useful. |