Missing file when making kernel 4.14.51
Not sure what happened here. I'm trying to upgrade my Linux kernel from 4.9.x to 4.14.x and the below happened:
In file included from arch/x86/decode.c:26:0:
arch/x86/../../elf.h:22:18: fatal error: gelf.h: No such file or directory
#include <gelf.h>
^
compilation terminated.
mv: cannot stat ‘/usr/src/linux-4.14.51/tools/objtool/arch/x86/.decode.o.tmp’: No such file or directory
make[4]: *** [/usr/src/linux-4.14.51/tools/objtool/arch/x86/decode.o] Error 1
make[3]: *** [arch/x86] Error 2
make[2]: *** [/usr/src/linux-4.14.51/tools/objtool/objtool-in.o] Error 2
make[1]: *** [objtool] Error 2
make: *** [tools/objtool] Error 2
Any ideas what happened here (other than the obvious)? Should "gelf.h" already be on my computer? Or in the kernel tarball?
I downloaded vanilla 4.14.51 from kernel.org - I've compiled my own (unmodified) vanilla kernel successfully, repeatedly, for 14 years now, but this is new.
My PC is a Dell laptop with Core2 i5 (64-bit) with Slackware 14.1 -- I upgraded the stock 3.17.x with 4.4.x several years ago, and more recently to 4.9.x (currently 4.9.109).
I do have libelf installed:
me@mylaptop:~$ locate gelf.h
/usr/include/libelf/gelf.h
me@mylaptop:~$ ls /var/log/packages/*elf*
/var/log/packages/libelf-0.8.13-x86_64-2
ADDENDUM
When trying 4.14.55 last night, I noted that the directory in which the kernel build script expects to see "gelf.h" is in the kernel source tree, not the regular /usr/include.
That being said, the corresponding directory in my (running) 4.9.x source tree does not have any .o nor .ko files. Obviously there's a config item enabled in 4.14.x that I don't have enabled in 4.9.x.
I've tried configuring 4.14.x as close to my working 4.9.x as possible; I am aware of some new options, but generally I try to keep the configurations the same between intermediate kernel versions.
That being said, I don't know what config option it is that would want to see the header files in linux-4.14.*/tools/objtool/arch/x86/... Any ideas?
linux kernel compile
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
add a comment |
Not sure what happened here. I'm trying to upgrade my Linux kernel from 4.9.x to 4.14.x and the below happened:
In file included from arch/x86/decode.c:26:0:
arch/x86/../../elf.h:22:18: fatal error: gelf.h: No such file or directory
#include <gelf.h>
^
compilation terminated.
mv: cannot stat ‘/usr/src/linux-4.14.51/tools/objtool/arch/x86/.decode.o.tmp’: No such file or directory
make[4]: *** [/usr/src/linux-4.14.51/tools/objtool/arch/x86/decode.o] Error 1
make[3]: *** [arch/x86] Error 2
make[2]: *** [/usr/src/linux-4.14.51/tools/objtool/objtool-in.o] Error 2
make[1]: *** [objtool] Error 2
make: *** [tools/objtool] Error 2
Any ideas what happened here (other than the obvious)? Should "gelf.h" already be on my computer? Or in the kernel tarball?
I downloaded vanilla 4.14.51 from kernel.org - I've compiled my own (unmodified) vanilla kernel successfully, repeatedly, for 14 years now, but this is new.
My PC is a Dell laptop with Core2 i5 (64-bit) with Slackware 14.1 -- I upgraded the stock 3.17.x with 4.4.x several years ago, and more recently to 4.9.x (currently 4.9.109).
I do have libelf installed:
me@mylaptop:~$ locate gelf.h
/usr/include/libelf/gelf.h
me@mylaptop:~$ ls /var/log/packages/*elf*
/var/log/packages/libelf-0.8.13-x86_64-2
ADDENDUM
When trying 4.14.55 last night, I noted that the directory in which the kernel build script expects to see "gelf.h" is in the kernel source tree, not the regular /usr/include.
That being said, the corresponding directory in my (running) 4.9.x source tree does not have any .o nor .ko files. Obviously there's a config item enabled in 4.14.x that I don't have enabled in 4.9.x.
I've tried configuring 4.14.x as close to my working 4.9.x as possible; I am aware of some new options, but generally I try to keep the configurations the same between intermediate kernel versions.
That being said, I don't know what config option it is that would want to see the header files in linux-4.14.*/tools/objtool/arch/x86/... Any ideas?
linux kernel compile
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
Locate doesn't guarantee the file is still there.
– Gerard H. Pille
Jun 26 '18 at 3:32
Umm, it's there on my system.stat $(locate gelf.h)gives a regular file of size 5103 bytes.cating that file shows what looks to be a bunch of C preprocessor code.Copyright (C) 2000 - 2006 Michael Riepe
– pr1268
Jun 26 '18 at 6:50
Another try: it looks as if you don't have elfutils. But then again: I wouldn't check /var/log for installed packages. Surely Slackware has some kind of package management? Could it be your Slackware itself could do with an update?
– Gerard H. Pille
Jun 26 '18 at 8:04
add a comment |
Not sure what happened here. I'm trying to upgrade my Linux kernel from 4.9.x to 4.14.x and the below happened:
In file included from arch/x86/decode.c:26:0:
arch/x86/../../elf.h:22:18: fatal error: gelf.h: No such file or directory
#include <gelf.h>
^
compilation terminated.
mv: cannot stat ‘/usr/src/linux-4.14.51/tools/objtool/arch/x86/.decode.o.tmp’: No such file or directory
make[4]: *** [/usr/src/linux-4.14.51/tools/objtool/arch/x86/decode.o] Error 1
make[3]: *** [arch/x86] Error 2
make[2]: *** [/usr/src/linux-4.14.51/tools/objtool/objtool-in.o] Error 2
make[1]: *** [objtool] Error 2
make: *** [tools/objtool] Error 2
Any ideas what happened here (other than the obvious)? Should "gelf.h" already be on my computer? Or in the kernel tarball?
I downloaded vanilla 4.14.51 from kernel.org - I've compiled my own (unmodified) vanilla kernel successfully, repeatedly, for 14 years now, but this is new.
My PC is a Dell laptop with Core2 i5 (64-bit) with Slackware 14.1 -- I upgraded the stock 3.17.x with 4.4.x several years ago, and more recently to 4.9.x (currently 4.9.109).
I do have libelf installed:
me@mylaptop:~$ locate gelf.h
/usr/include/libelf/gelf.h
me@mylaptop:~$ ls /var/log/packages/*elf*
/var/log/packages/libelf-0.8.13-x86_64-2
ADDENDUM
When trying 4.14.55 last night, I noted that the directory in which the kernel build script expects to see "gelf.h" is in the kernel source tree, not the regular /usr/include.
That being said, the corresponding directory in my (running) 4.9.x source tree does not have any .o nor .ko files. Obviously there's a config item enabled in 4.14.x that I don't have enabled in 4.9.x.
I've tried configuring 4.14.x as close to my working 4.9.x as possible; I am aware of some new options, but generally I try to keep the configurations the same between intermediate kernel versions.
That being said, I don't know what config option it is that would want to see the header files in linux-4.14.*/tools/objtool/arch/x86/... Any ideas?
linux kernel compile
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
Not sure what happened here. I'm trying to upgrade my Linux kernel from 4.9.x to 4.14.x and the below happened:
In file included from arch/x86/decode.c:26:0:
arch/x86/../../elf.h:22:18: fatal error: gelf.h: No such file or directory
#include <gelf.h>
^
compilation terminated.
mv: cannot stat ‘/usr/src/linux-4.14.51/tools/objtool/arch/x86/.decode.o.tmp’: No such file or directory
make[4]: *** [/usr/src/linux-4.14.51/tools/objtool/arch/x86/decode.o] Error 1
make[3]: *** [arch/x86] Error 2
make[2]: *** [/usr/src/linux-4.14.51/tools/objtool/objtool-in.o] Error 2
make[1]: *** [objtool] Error 2
make: *** [tools/objtool] Error 2
Any ideas what happened here (other than the obvious)? Should "gelf.h" already be on my computer? Or in the kernel tarball?
I downloaded vanilla 4.14.51 from kernel.org - I've compiled my own (unmodified) vanilla kernel successfully, repeatedly, for 14 years now, but this is new.
My PC is a Dell laptop with Core2 i5 (64-bit) with Slackware 14.1 -- I upgraded the stock 3.17.x with 4.4.x several years ago, and more recently to 4.9.x (currently 4.9.109).
I do have libelf installed:
me@mylaptop:~$ locate gelf.h
/usr/include/libelf/gelf.h
me@mylaptop:~$ ls /var/log/packages/*elf*
/var/log/packages/libelf-0.8.13-x86_64-2
ADDENDUM
When trying 4.14.55 last night, I noted that the directory in which the kernel build script expects to see "gelf.h" is in the kernel source tree, not the regular /usr/include.
That being said, the corresponding directory in my (running) 4.9.x source tree does not have any .o nor .ko files. Obviously there's a config item enabled in 4.14.x that I don't have enabled in 4.9.x.
I've tried configuring 4.14.x as close to my working 4.9.x as possible; I am aware of some new options, but generally I try to keep the configurations the same between intermediate kernel versions.
That being said, I don't know what config option it is that would want to see the header files in linux-4.14.*/tools/objtool/arch/x86/... Any ideas?
linux kernel compile
linux kernel compile
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
edited Jul 13 '18 at 10:58
pr1268
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
asked Jun 26 '18 at 2:43
pr1268pr1268
1063
1063
Locate doesn't guarantee the file is still there.
– Gerard H. Pille
Jun 26 '18 at 3:32
Umm, it's there on my system.stat $(locate gelf.h)gives a regular file of size 5103 bytes.cating that file shows what looks to be a bunch of C preprocessor code.Copyright (C) 2000 - 2006 Michael Riepe
– pr1268
Jun 26 '18 at 6:50
Another try: it looks as if you don't have elfutils. But then again: I wouldn't check /var/log for installed packages. Surely Slackware has some kind of package management? Could it be your Slackware itself could do with an update?
– Gerard H. Pille
Jun 26 '18 at 8:04
add a comment |
Locate doesn't guarantee the file is still there.
– Gerard H. Pille
Jun 26 '18 at 3:32
Umm, it's there on my system.stat $(locate gelf.h)gives a regular file of size 5103 bytes.cating that file shows what looks to be a bunch of C preprocessor code.Copyright (C) 2000 - 2006 Michael Riepe
– pr1268
Jun 26 '18 at 6:50
Another try: it looks as if you don't have elfutils. But then again: I wouldn't check /var/log for installed packages. Surely Slackware has some kind of package management? Could it be your Slackware itself could do with an update?
– Gerard H. Pille
Jun 26 '18 at 8:04
Locate doesn't guarantee the file is still there.
– Gerard H. Pille
Jun 26 '18 at 3:32
Locate doesn't guarantee the file is still there.
– Gerard H. Pille
Jun 26 '18 at 3:32
Umm, it's there on my system.
stat $(locate gelf.h) gives a regular file of size 5103 bytes. cating that file shows what looks to be a bunch of C preprocessor code. Copyright (C) 2000 - 2006 Michael Riepe– pr1268
Jun 26 '18 at 6:50
Umm, it's there on my system.
stat $(locate gelf.h) gives a regular file of size 5103 bytes. cating that file shows what looks to be a bunch of C preprocessor code. Copyright (C) 2000 - 2006 Michael Riepe– pr1268
Jun 26 '18 at 6:50
Another try: it looks as if you don't have elfutils. But then again: I wouldn't check /var/log for installed packages. Surely Slackware has some kind of package management? Could it be your Slackware itself could do with an update?
– Gerard H. Pille
Jun 26 '18 at 8:04
Another try: it looks as if you don't have elfutils. But then again: I wouldn't check /var/log for installed packages. Surely Slackware has some kind of package management? Could it be your Slackware itself could do with an update?
– Gerard H. Pille
Jun 26 '18 at 8:04
add a comment |
1 Answer
1
active
oldest
votes
I have been having a very similar issue while upgrading my kernel in Slackware 14.1 with essentially the same error. I'm very new to the kernel business, but I believe that installing the libelf library will correct the issue. It is documented here:
https://directory.fsf.org/wiki/Libelf
Additionally, I believe that the issue is supposed to be caught by the default make behaviour, but it is not. I could be totally wrong on that count, but here is a related patch to make that Slackware 14.1 does not have:
https://lore.kernel.org/patchwork/patch/670761/
answered Jan 28 at 22:53
HoserHoser
1
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1334202%2fmissing-file-when-making-kernel-4-14-51%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I have been having a very similar issue while upgrading my kernel in Slackware 14.1 with essentially the same error. I'm very new to the kernel business, but I believe that installing the libelf library will correct the issue. It is documented here:
https://directory.fsf.org/wiki/Libelf
Additionally, I believe that the issue is supposed to be caught by the default make behaviour, but it is not. I could be totally wrong on that count, but here is a related patch to make that Slackware 14.1 does not have:
https://lore.kernel.org/patchwork/patch/670761/
answered Jan 28 at 22:53
HoserHoser
1
add a comment |
I have been having a very similar issue while upgrading my kernel in Slackware 14.1 with essentially the same error. I'm very new to the kernel business, but I believe that installing the libelf library will correct the issue. It is documented here:
https://directory.fsf.org/wiki/Libelf
Additionally, I believe that the issue is supposed to be caught by the default make behaviour, but it is not. I could be totally wrong on that count, but here is a related patch to make that Slackware 14.1 does not have:
https://lore.kernel.org/patchwork/patch/670761/
answered Jan 28 at 22:53
HoserHoser
1
add a comment |
I have been having a very similar issue while upgrading my kernel in Slackware 14.1 with essentially the same error. I'm very new to the kernel business, but I believe that installing the libelf library will correct the issue. It is documented here:
https://directory.fsf.org/wiki/Libelf
Additionally, I believe that the issue is supposed to be caught by the default make behaviour, but it is not. I could be totally wrong on that count, but here is a related patch to make that Slackware 14.1 does not have:
https://lore.kernel.org/patchwork/patch/670761/
answered Jan 28 at 22:53
HoserHoser
1
I have been having a very similar issue while upgrading my kernel in Slackware 14.1 with essentially the same error. I'm very new to the kernel business, but I believe that installing the libelf library will correct the issue. It is documented here:
https://directory.fsf.org/wiki/Libelf
Additionally, I believe that the issue is supposed to be caught by the default make behaviour, but it is not. I could be totally wrong on that count, but here is a related patch to make that Slackware 14.1 does not have:
https://lore.kernel.org/patchwork/patch/670761/
answered Jan 28 at 22:53
HoserHoser
1
answered Jan 28 at 22:53
HoserHoser
1
answered Jan 28 at 22:53
HoserHoser
1
answered Jan 28 at 22:53
HoserHoser
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1334202%2fmissing-file-when-making-kernel-4-14-51%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Locate doesn't guarantee the file is still there.
– Gerard H. Pille
Jun 26 '18 at 3:32
Umm, it's there on my system.
stat $(locate gelf.h)gives a regular file of size 5103 bytes.cating that file shows what looks to be a bunch of C preprocessor code.Copyright (C) 2000 - 2006 Michael Riepe– pr1268
Jun 26 '18 at 6:50
Another try: it looks as if you don't have elfutils. But then again: I wouldn't check /var/log for installed packages. Surely Slackware has some kind of package management? Could it be your Slackware itself could do with an update?
– Gerard H. Pille
Jun 26 '18 at 8:04