1

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?

Improve this question
3
  • Locate doesn't guarantee the file is still there.
    – Gerard H. Pille
    Commented Jun 26, 2018 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
    Commented Jun 26, 2018 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
    Commented Jun 26, 2018 at 8:04

2 Answers 2

Reset to default
2

I'm testing Phoronix build-linux-kernel. Met the same missing <gelf.h> problem.

sudo apt install libelf-dev

Solved the problem.

Improve this answer
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/

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .