With the latest gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 compiler tools release, g++ is very slow to compile relative to the older gcc-arm-none-eabi-7-2017-q4-major-linux.tar.bz2 release.
I am seeing it take over 3 times longer than the previous compiler. A previously 45 second build now takes 2.5 minutes.
Is this to be expected ?
Are there any compiler flags that will speed this up (less optimisations) as it is now taking a significant time to build things ?
A co-worker (GitHub @jepler) and I confirmed that the builds are not optimized: they are built without `-O2`. Between the 7-2018-q2 and 8-2018-q4 releases, some changes involving `CXXFLAGS` were made to `build-toolchain.sh`.
This diff makes optimized builds, though you may want to do it a different way, as we don't know the context for the CXXFLAGS changes.
--- /home/someone/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-toolchain.sh 2019-07-03 21:19:47.000000000 -0500 +++ ./build-toolchain.sh 2019-08-15 11:22:41.081622816 -0500 @@ -149,7 +149,7 @@ done fi -CXXFLAGS= +CXXFLAGS="-O2 -g" if [ "x$BUILD" == "xx86_64-apple-darwin10" ] || [ "x$is_ppa_release" == "xyes" ]; then skip_mingw32=yes skip_mingw32_gdb_with_python=yes
Terry, Thanks for reporting and analyzing the issue. It is a confirmed bug in the build script and has just been fixed, in a way slightly different to what you shared. The updated script and binary package will be included in the next release.
Thanks for fixing this bug. Note it was Dan Halbert and his co-worker who actually tracked it down.
Joey, thanks for confirming this is the issue. Are you folks willing to make an interim re-release of 8-2019-q3 that fixes the problem? We'd like to move on to a newer version, but would rather not wait until December or January. As it stands the current compile times are so long that they would make our development cycle unpleasant, and make our CI jobs interminably long.
We could build it ourselves, but the build is painful and I haven't yet gotten a completely working gcc build.
Dan, Due to resource constraint we have no plan to introduce an additional release before the planned one. The solution I would suggest is to stay with the old version for a while, or build your own version. May I know which part of building process is painful for you so that we can probably improve the how-to-build manual?