Post by John Crispin
whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?
I think the kernel situation is ok now and not blocking a release, we
will have a mixed kernel 4.9 and 4.14 release. All important targets are
on one of these two kernel versions by now.
The patches for the gemini target will probably get included soon.
Some targets will probably be updated from 4.9 to 4.14, but this is not
What do we want to do with GCC 5.5 versus 7.3?
GCC 5.5 is getting old, we have multiple problems with it, the big
blocker for GCC 7 was just fixed upstream and we backported that fix.
The x86 and x86_64 architectures are already on GCC 7.3, the ARC
architecture uses their own GCC fork based on version 7.X all other
architectures are on GCC 5.5.
We have the following problems with GCC 5.5:
* U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
* GCC 5 and older are producing too big binaries, e.g. the SPL on the
Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
* busybox on the gemini target updated to kernel 4.14 does not work
* GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
the retpoline fixes against Spectre included
As the x86 target use GCC 7.3 now, there are multiple pull requests
fixing some build problems in some packages with GCC 7.
I am not aware of any regressions in GCC 7 compared to GCC 5.
Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
problems are the regressions we are not aware of by now, if we change
the default compiler for all architectures to GCC 7 we should probably
wait 4 weeks before doing an RC release to be sure most of the runtime
problems with GCC 7 are found.
If we do the switch to GCC 7 I think we should also change binutils from
2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
was already fixed in 2.28.1:
The minor versions contains more bugfixes.
There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
I do not have a real opinion on this and I am probably the wrong person
to judge this.
I do not know what the status of the software fast path patches are, but
they are looking interesting.
My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.