GCC next builds failing in nightly builds and waterfall builders *-gcc-toolchain |
||||
Issue descriptiongcc builds in nightly cron jobs and *-gcc-toolchain builder are failing in setupBoard. Log link for x86-gcc-toolchain builder: https://uberchromegw.corp.google.com/i/chromeos/builders/x86-gcc-toolchain/builds/92/steps/SetupBoard/logs/stdio Some errors from the log: gfdl.pod around line 53: Expected text after =item, not a number gfdl.pod around line 147: Expected text after =item, not a number gfdl.pod around line 165: Expected text after =item, not a number gfdl.pod around line 205: Expected text after =item, not a number gfdl.pod around line 357: Expected text after =item, not a number gfdl.pod around line 384: Expected text after =item, not a number gfdl.pod around line 400: Expected text after =item, not a number gfdl.pod around line 422: Expected text after =item, not a number gfdl.pod around line 445: Expected text after =item, not a number gfdl.pod around line 475: Expected text after =item, not a number gfdl.pod around line 499: Expected text after =item, not a number POD document had syntax errors at /usr/bin/pod2man line 68. make[2]: [Makefile:2999: doc/gfdl.7] Error 1 (ignored) Fixing headers into /var/tmp/portage/cross-i686-pc-linux-gnu/gcc-4.9.2-r145/work/gcc-4.9.2-build-i686-pc-linux-gnu/gcc/include-fixed for i686-pc-linux-gnu target Forbidden identifiers: i386 linux unix Finding directories and links to directories Searching /usr/i686-pc-linux-gnu/usr/include/. Making symbolic directory links Fixing directory /usr/i686-pc-linux-gnu/usr/include into /var/tmp/portage/cross-i686-pc-linux-gnu/gcc-4.9.2-r145/work/gcc-4.9.2-build-i686-pc-linux-gnu/gcc/include-fixed Applying (null) to printf.h /bin/sh: line 1: syntax error near unexpected token `(' /bin/sh: line 1: `/* Copyright (C) 1991-2014 Free Software Foundation, Inc.' Applying (null) to sysexits.h /bin/sh: line 1: /b: Is a directory
,
Dec 21 2016
Any updates? All gcc builders, including nightly performance tests, are failing.
,
Jan 3 2017
No real progress. :-(
,
Jan 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/fe506eceab9eb805ca87d8ae73215476c53fe9a5 commit fe506eceab9eb805ca87d8ae73215476c53fe9a5 Author: Caroline Tice <cmtice@google.com> Date: Thu Jan 05 00:24:47 2017 [GCC] Fix building gcc with USE='next_gcc'. A change committed upstream in Feb. 2016 is causing the next_gcc emerges to fail. This CL applies a patch to GCC, when building with USE='next_gcc', that undoes the upstream fix. This is intended to be a temporary workaround while we investigate and fix the actual problem with the upstream change. BUG= chromium:673427 TEST=Emerged gcc, using USE='next_gcc' with this CL. Change-Id: I284ab9cfcebc3afb03dcee1b7d2790da41debb36 Reviewed-on: https://chromium-review.googlesource.com/424958 Commit-Ready: Caroline Tice <cmtice@chromium.org> Tested-by: Caroline Tice <cmtice@chromium.org> Reviewed-by: Yunlian Jiang <yunlian@chromium.org> [modify] https://crrev.com/fe506eceab9eb805ca87d8ae73215476c53fe9a5/sys-devel/gcc/gcc-9999.ebuild [add] https://crrev.com/fe506eceab9eb805ca87d8ae73215476c53fe9a5/sys-devel/gcc/files/gcc-4.9-gcc_next-fixincludes.patch
,
Jan 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/74f0864e63620c2312dd0f858c0354a5114909f6 commit 74f0864e63620c2312dd0f858c0354a5114909f6 Author: Caroline Tice <cmtice@google.com> Date: Fri Jan 06 17:43:57 2017 [GCC] Undo temporary patch from CL 424958 CL 424958 added a temporary patch to fix building with next_gcc, while we found and fixed the real issue. The real issue has been found and fixed in the GCC repository, so the temporary patch is no longer needed; this CL removes it. BUG= chromium:673427 TEST=Emerged gcc_next with this CL. Change-Id: I39fb43214290872637844acc579a7e44368316ee Reviewed-on: https://chromium-review.googlesource.com/425821 Commit-Ready: Caroline Tice <cmtice@chromium.org> Tested-by: Caroline Tice <cmtice@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Yunlian Jiang <yunlian@chromium.org> [modify] https://crrev.com/74f0864e63620c2312dd0f858c0354a5114909f6/sys-devel/gcc/gcc-9999.ebuild [delete] https://crrev.com/f8dea149c230bd061d3664c78c1924a94cfa914e/sys-devel/gcc/files/gcc-4.9-gcc_next-fixincludes.patch
,
Jan 9 2017
We finally got the issues fixed with downloading and building the GCC "next" compiler in ChromeOS. However, now that we've got the compiler it's consistently failing to build 3-4 packages (depending on which architecture you're using): sys-devel/binutils (all archs) net-misc/iperf (all archs) chromeos-base/verify (all archs) dev-libs/boost (arm, arm64, x86_64) I'm in the process of investigating and trying to fix this now.
,
Jan 18 2017
Issue 682426 has been merged into this issue.
,
Jan 19 2017
The following change has been committed to the svn branch for this GCC compiler. It should fix the problem...give the svn mirrors about 24 hours to pick up the change. Index: libstdc++-v3/configure.host =================================================================== --- libstdc++-v3/configure.host (revision 244382) +++ libstdc++-v3/configure.host (working copy) @@ -81,7 +81,7 @@ # Try to guess a default cpu_include_dir based on the name of the CPU. We # cannot do this for os_include_dir; there are too many portable operating # systems out there. :-) -c_model=c_google +c_model=c_global c_compatibility=no atomic_word_dir=cpu/generic atomic_flags="" Index: libstdc++-v3/include/tr1/complex =================================================================== --- libstdc++-v3/include/tr1/complex (revision 244382) +++ libstdc++-v3/include/tr1/complex (working copy) @@ -316,8 +316,8 @@ { typedef typename __gnu_cxx::__promote<_Tp>::__type __type; #if (_GLIBCXX_USE_C99_MATH && !_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC) - return ::signbit(__x) ? __type(3.1415926535897932384626433832795029L) - : __type(); + return std::signbit(__x) ? __type(3.1415926535897932384626433832795029L) + : __type(); #else return std::arg(std::complex<__type>(__x)); #endif
,
Jan 20 2017
,
Mar 17 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by manojgupta@chromium.org
, Dec 12 2016