Red Hat Bugzilla – Bug 892373
3.7.1-2.fc18 - include/linux/version.h prevents kernel modules compiling
Last modified: 2013-01-19 22:57:18 EST
Description of problem:
I'm unable to compile most thirdparty kernel modules due to an empty /usr/src/kernels/3.7.1-2.fc18.x86_64/include/linux/version.h file
Version-Release number of selected component (if applicable):
Every compile fails
Steps to Reproduce:
Try and compile nvidia (310.19) or virtualbox (4.2.4) with kernel 3.7.1-2.fc18
I expect it to compile
deleting /usr/src/kernels/3.7.1-2.fc18.x86_64/include/linux/version.h fixes the compile issue.
surely this file is obsolete now as it's been replaced by /usr/src/kernels/3.7.1-2.fc18.x86_64/include/generated/uapi/linux/version.h
fixed in git.
*** Bug 892138 has been marked as a duplicate of this bug. ***
*** Bug 892974 has been marked as a duplicate of this bug. ***
*** Bug 893039 has been marked as a duplicate of this bug. ***
kernel-3.7.1-5.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.7.1-5.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
*** Bug 894490 has been marked as a duplicate of this bug. ***
well the zero-byte file is now away, nice would be the symlink directly
dunno what upstream thinks here by moving things around
ln -s /usr/src/kernels/3.7.2-201.fc18.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.2-201.fc18.x86_64/include/linux/version.h
kernel-3.7.2-201.fc18 has been submitted as an update for Fedora 18.
kernel-3.7.2-201.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I'm running 3.7.2-201.fc18.x86_64, and version.h is still missing from the kernel source tree (/usr/src/kernels/3.7.2-201.fc18.x86_64/include/linux/).
I had to link version.h from the kernel-headers (/usr/include/linux/version.h) as Comment #8, before being able to recompile VMware modules.
Any intention to fix this behavior?
correct, it would be fine to have this symlink in the package
but now it is better than before where te location existed as zero-byte file leading any onlie-instructions for set the symlink to fail
(In reply to comment #11)
> (/usr/include/linux/version.h) as Comment #8, before being able to recompile
> VMware modules.
Try filing a bug report against vmware as it's their issue now, they need to add 3.7 kernel support.
> Any intention to fix this behavior?
Should should ask the vmware developers.
Leigh, so you mean that version.h was moved in linux 3.7 ?
I haven't heard of it, but if this is the case, then yyeah, vmware (and all others) should update their stuff.
(In reply to comment #14)
> Leigh, so you mean that version.h was moved in linux 3.7 ?
Sorry this is the best link I could find for the headers files move
> I haven't heard of it, but if this is the case, then yyeah, vmware (and all
> others) should update their stuff.
*** Bug 896539 has been marked as a duplicate of this bug. ***
I would think that if this has changed in the 3.7.x series that companies like AMD and VMWare would already have fixed it. However, I just downloaded the installer for the AMD ATI Driver (dated 1-9-2013) and it's still looking in the wrong location.
In my case, they are looking in
/lib/modules/3.7.2-201.fc18.x86_64/build/include/linux/version.h not /usr/include/linux/version.h directly.
Wouldn't it be easier to just create the symlink when the headers and kernel source are installed? I realize that it's a workaround--not a fix, and that the "fix" falls on the various projects/applications.
Have a great day:)
technically this would be easy - but i gave up to hope that opensource-developers come up with pragmatic solutions because in context of software not in the repos they are infected by the NIH-syndrome (Not Invented Here)