[Backport to 6.0.5.0] Use gcc 8 for linux-pkg (#107)

[pzakha]

The 5.4 kernel headers define CONFIG_CC_HAS_ASM_INLINE, which prevents
kernel modules from being compiled with gcc 7.

Clean cherry-pick. This work is required for bumping our kernel in 6.0.5.0.

Testing

• linux-pkg-build userland: http://selfservice.jenkins.delphix.com/job/devops-gate/job/master/job/linux-pkg-build/job/6.0/job/stage/job/userland/job/pre-push/92/
• linux-pkg-build kernel: http://selfservice.jenkins.delphix.com/job/devops-gate/job/master/job/linux-pkg-build/job/6.0/job/stage/job/kernel/job/pre-push/49/
• ab-pre-push: http://selfservice.jenkins.delphix.com/job/devops-gate/job/master/job/appliance-build-orchestrator-pre-push/3943/

[sebroy]

I assume that this task will run each time a build job kicks off. Can you describe the tradeoffs between doing this here rather than encoding this logic into the automation that creates the bootstrap golden image used for builds?

[pzakha]

@sebroy We are using the same bootstrap image to build every version of Delphix, and some of the older versions do not use gcc 8. Ideally we should not modify the bootstrap image after it has been produced.

Also, we were considering the idea of having multiple bootstrap images for different versions of Delphix, but this is a project for the future.

[sebroy]

@sebroy We are using the same bootstrap image to build every version of Delphix, and some of the older versions do not use gcc 8. Ideally we should not modify the bootstrap image after it has been produced.

Thanks, that makes sense. At the same time, it feels like if we're using gcc8 by default going forward to build all linux-pkg repos, then should we also use the same version of gcc to build C code in other repos? I suppose this question/concern could be addressed by bringing all builds under linux-pkg (e.g. dlpx-app-gate, dms-core-gate, etc.), right?

[sdimitro]

I don't know if Pavel and John discussed any other points but personally I prefer having gcc-8 here and not spread the dependency in the bootstrap VM setup because it makes linux-pkg more self-contained. I tend to work on linux-pkg on stock dlpx-trunk VMs instead of bootstrap VMs and I really appreciate the fact that there is no such requirement.

[pzakha]

That's a good point Serapheim, and yes having linux-pkg being self-contained is also an objective I'm going for. Eventually we may be able to use docker to build some packages, for more flexibility or to save the need to create a new VM every time we need to build something.

I suppose this question/concern could be addressed by bringing all builds under linux-pkg (e.g. dlpx-app-gate, dms-core-gate, etc.), right?

Seb, yes that's something I have in my sights.