View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001028channel: kernel/el7kernel-mlpublic2020-07-31 02:342021-04-29 16:35
Reporterberthajm Assigned Toburakkucat  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
Summary0001028: kernel-ml-devel 5.7 has the CONFIG_CC_HAS_ASM_INLINE flag set - but RHEL 7 has gcc 4.8.5 not supporting it
Descriptionkernel-ml-devel package for RHEL 7 since kernel 5.7 appears to be compiled with gcc > 8.
So it has the CONFIG_CC_HAS_ASM_INLINE set in include/generated/autoconf.h.

This is wrong since RHEL 7 has gcc 4.8.5, not supporting asm inline. So this is creating all kind of blocking problems for users.
In particular on VirtualBox when the kernel module is built on install, plenty of errors are generated because of that flag, and the install/build fails, making VirtualBox unusable.

Simply commenting out

//#define CONFIG_CC_HAS_ASM_INLINE 1

in autoconf.h allows VirtualBox to build properly and cleanly, so this seems to be the only problem generated currently.
Additional Informationhttps://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849348
https://forums.virtualbox.org/viewtopic.php?f=7&t=96297&sid=3dbd55b7e26d4a2aed9c417ab942ab0f&start=15
https://www.virtualbox.org/ticket/19244
https://github.com/torvalds/linux/commit/eb111869301e15b737315a46c913ae82bd19eb9d

Complete file path in 5.7.11:
/usr/src/kernels/5.7.11-1.el7.elrepo.x86_64/include/generated/autoconf.h
TagsNo tags attached.

Relationships

related to 0001023 resolvedburakkucat Kernel-ml for el7, using the linux sources > 5.8-rc4, now cannot be built because it requires a newer version of gcc 

Activities

pperry

2020-07-31 03:16

administrator   ~0007106

Hi,

Thank you for raising this.

As of kernel-5.8, upstream kernel.org have raised the minimum gcc requirement to gcc-4.9 which means the distro shipped gcc-4.8.5 can no longer be used to build kernel-ml on RHEL7.

Rather than dropping ongoing support for kernel-ml on el7, we are experimenting with the newer gcc-9.3.1 available in the SCL dev toolset.

We will have to try to address issues like this as they arise, and figure out if it is something we can overcome, or something users can work around locally.

What solution would you like to see? Are you able to submit a patch?

Thanks,

Phil

pperry

2020-07-31 04:44

administrator   ~0007107

Not suggesting that this is an optimal solution, but another workaround is to use the same gcc-4.9 from the SCL dev toolset to build the VirtualBox modules as was used to build the kernel.

$ sudo yum --enable rhel-server-rhscl-7-rpms install devtoolset-9-gcc
$ scl enable devtoolset-9 bash
$ gcc -v
(snip)
gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC)

This blog post may also be useful:

http://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-dts-in.html

pperry

2020-07-31 04:52

administrator   ~0007108

CentOS rebuilds devtoolset-9 here:

http://mirrors.coreix.net/centos/7/sclo/x86_64/rh/Packages/d/

berthajm

2020-07-31 05:59

reporter   ~0007110

Thank you. Workable solutions / workaround for developers, but not for normal users from my view.

Any application which requires some kernel module build like VirtualBox is bound to hit the problem.
Users of VirtualBox for example, are often simple users who need to run some business applications which are only in Windows, so they install things following dependency chains and are not able to find the origin of a problem, and then to identify they need by themselves to install more or to adjust a .h file somewhere ..

The solution should be to find a way to use the distro gcc for such installs, and only require gcc 9 when somebody wants to rebuild the kernel, which is a very marginal number of cases I believe.

A simple suggestion along that line:
------------------------------------
A possibility could be to generate two include/generated/autoconf.h (and also I guess two include/config/auto.conf):
- one with normal name, without the flag
- one with a modified name like autoconf.h.kerneldev, which has the flag

Then a normal user will have a transparent behavior.
A kernel developer will have to rename first the autoconf.h files, but this is something easy that kind of person ..

pperry

2020-07-31 10:13

administrator   ~0007111

Having considered this bug we feel this is not something we should "fix".

In order to ensure compatibility, it is important that any kernel modules built against kernel-ml (kernel-ml-devel) are built using the same compiler as is used to build the kernel itself.

As we are unable to continue to use the distro gcc compiler due to minimum version requirements introduced upstream (kernel.org), likewise anyone wishing to compile 3rd party kernel modules against this kernel release should also use the same compiler version for compatibility reasons. As this bug highlights, failing to do so can cause compatibility issues and trying to paper over them, whilst it may work in some cases, is not the correct approach. By using the SCL devtoolset gcc-9 compiler rather than a customer compiler solution, we are ensuring that end users have the same tools readily available as we have used to build the kernel.

Thus, in this particular case, before running the command/script used to build the VirtualBox module(s), to ensure compatibility we recommend enabling and using the devtoolset gcc-9 compiler as described above.

berthajm

2020-07-31 10:46

reporter   ~0007112

That is a good way to look at things I believe, but then shouldn't kernel-ml-devel require the gcc 9 package as pre-req to be installed ?

And then:
- include the commands to enable that software collection and to then get devtoolset-9-gcc installed as required package at the same time
- or simply get it installed or enable by the ELRepo install package or instructions on the home page http://elrepo.org/tiki/tiki-index.php

for things to work smoothly and properly, and avoid that people fall into the problem without knowing how to resolve ?

pperry

2020-07-31 12:00

administrator   ~0007113

Acknowledged, we can certainly look at ways to try to better manage this for end users, be that better documentation or other solutions.

berthajm

2020-07-31 16:50

reporter   ~0007114

I can only agree.
If you need me to test something, let me know.
Thank you for the swift responses.

pjwelsh

2020-08-21 10:40

reporter   ~0007157

Using devtoolset-9 does not seem to be enough for VirtualBox module building:
scl enable devtoolset-9 bash
gcc -v
...
gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC)
/sbin/vboxconfig = fail
(from /var/log/vbox-setup.log
"In file included from ././include/linux/compiler_types.h:68:0,
                 from <command-line>:0:
./include/linux/compiler-gcc.h:15:3: error: #error Sorry, your compiler is too old - please upgrade it.
 # error Sorry, your compiler is too old - please upgrade it."

VB still seems to use stock gcc (from /var/log/vbox-setup.log):
gcc -Wp,-MMD,/tmp/vbox.0/r0drv/.alloc-r0drv.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include

Any idea how to get past?

burakkucat

2020-08-22 07:32

administrator   ~0007162

I know nothing about virtualbox, be it compilation, installation or usage.

The "magic" in the kernel-{lt|ml} specification files is just --

. /opt/rh/devtoolset-9/enable

I.e. the "enable" script of the devtoolset-9 package is sourced immediately after the calls of the %prep, %build and %install macros.

Perhaps a similar line should be added to the virtualbox "whatever" script file?

toracat

2020-10-10 19:51

administrator   ~0007220

[copied from the old site]

(0007221)
berthajm (reporter)
2020-10-02 14:23

@pjwelsh, I explored @burakkucat suggestion and I found a way to get around the problem.

The reason for not being able to use "scl enable" directly comes from the fact that the kernel module recompile is started through a systemctl service call, so in a different process than /sbin/vboxconfig, and therefore it doesn't inherit the "scl enable" environment.


So here it is, once you have installed devtoolset-9:

1) Copy /usr/src/kernels/<kernel-version>.elrepo.x86_64/include/linux/autoconf.h into include/generated (for some reason that I didn't have time to dig, VirtualBox still tries to find it there, although it is supposed to work with kernels 5.8 from 6.1.14)

2) As root, edit /usr/lib/virtualbox/vboxdrv.sh
- Find and replace
      BUILDINTMP="${MODULE_SRC}/build_in_tmp"
  by
      BUILDINTMP="/bin/scl enable devtoolset-9 -- ${MODULE_SRC}/build_in_tmp"

3) As root, execute /bin/vboxconfig

Then when restarting VirtualBox, all is ok

Of course, on each kernel reinstall / upgrade, you'll have to redo 1), and on each VirtualBox upgrade, you'll have to redo 2).


I hope this helps. It works for me on 5.8.

burakkucat

2021-04-29 16:35

administrator   ~0007570

With suitable scripting, end-users can automate steps 1, 2 & 3 from note 7220 (above) (note 7221 on the old site).

Now closing as "no change required".

Issue History

Date Modified Username Field Change
2020-07-31 02:34 berthajm New Issue
2020-07-31 02:34 berthajm Status new => assigned
2020-07-31 02:34 berthajm Assigned To => burakkucat
2020-07-31 03:16 pperry Note Added: 0007106
2020-07-31 04:44 pperry Note Added: 0007107
2020-07-31 04:45 pperry Relationship added related to 0001023
2020-07-31 04:52 pperry Note Added: 0007108
2020-07-31 05:59 berthajm Note Added: 0007110
2020-07-31 10:13 pperry Note Added: 0007111
2020-07-31 10:46 berthajm Note Added: 0007112
2020-07-31 12:00 pperry Note Added: 0007113
2020-07-31 16:50 berthajm Note Added: 0007114
2020-08-21 10:40 pjwelsh Note Added: 0007157
2020-08-22 07:32 burakkucat Note Added: 0007162
2020-10-10 19:51 toracat Note Added: 0007220
2021-04-29 16:35 burakkucat Status assigned => closed
2021-04-29 16:35 burakkucat Resolution open => no change required
2021-04-29 16:35 burakkucat Note Added: 0007570