[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel 4.14.15 compilation using GCC 8 in unstable.......





On 26 January 2018 at 16:17, Michael Fothergill <michael.fothergill@gmail.com> wrote:





Hi, sorry to jump into the thread this late, I didn't follow the beginning.
You can save yourself quite a bit of hassle by downloading the upstream up-to-date vanilla kernel 4.15-rc9 and compile that with Unstable gcc-7.
All you need is there already and you will get as good a mitigation for Spectre as one can get right now.

​Is the 7.2 kernel in sid gcc 7 really gassed up enough to compile the spectre fix in a way that the meltdown-spectre checker will say that the compiler used
was adequate to make the kernel fix work properly?

​Oops I made an error here. I meant to say:

Is the 7.2 version of the compiler in sid gcc 7 ​really gassed up enough to compile the spectre fix in a way that the meltdown-spectre checker will say that the compiler used
was adequate to make the kernel fix work properly?

Cheers
 
MF


 
​ A backport from GCC 8 to 7 has to be made to make it work - I thought this was only done in 7.3.......

​Is the sid gcc now 7.3 as someone said earlier even though it says it is 7.2?

I don't want to have to uninstall gcc 8 only to have to reinstall it again.

MF​


 
After configuration you can use the build target "make bindeb-pkg" or use the "make-kpkg" command from kernel-package (to be installed and configured, the doc will guide you).
Also you need basic build environment, and "libelf-dev" if you choose the ORC unwinder. For the build environment look at kernel-package dependencies.

If you want to stay mainly in Testing but cherry pick Unstable packages (and benefit from apt/aptitude dependencies resolution) you can look into apt-pinning, giving Unstable package a priority of 101 should do the trick, something like:

Package: *
Pin: release a=unstable
Pin-Priority: 101

in /etc/apt/preferences, coupled with:

APT::Default-Release "buster";

in /etc/apt/apt.conf


I would not pull critical packages from experimental unless it is absolutely necessary, dragons are lurking in there.

Hope it helps.




Reply to: