Home | News | Download | Packages | Forum | Wiki | Github

Trying to Compile 4.14.18 Custom Kernel


I was pleased to see that the 4.14.18 kernel passed the spectre/meltdown tests [github.com/speed47/spectre-meltdown-checker.sh].

However, I tried to compile a custom [module-free] 4.14.18 kernel from the kernel.org source. The last time I achieved this was November 2016 [4.5.2 kernel]. Since then I have fully upgraded my system. This time I get a fatal error complaining that gelf.h is missing [full message below]. Is this caused by a new package that I must xbps-install? Ideas?

thanks, jacksprat

here is the output from building a with a “minimal” custom .config [but errors also stop the build with a default .config; different errors]:

CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
DESCEND objtool
:1:10: fatal error: libelf.h: No such file or directory
compilation terminated.
CC /home/jack/news/src/linux/linux-4.14.18/tools/objtool/arch/x86/decode.o
In file included from arch/x86/decode.c:26:0:
arch/x86/…/…/elf.h:22:10: fatal error: gelf.h: No such file or directory
#include <gelf.h>
compilation terminated.
mv: cannot stat ‘/home/jack/news/src/linux/linux-4.14.18/tools/objtool/arch/x86/.decode.o.tmp’: No such file or directory
make[4]: *** [/home/jack/news/src/linux/linux-4.14.18/tools/build/Makefile.build:97: /home/jack/news/src/linux/linux-4.14.18/tools/objtool/arch/x86/decode.o] Error 1
make[3]: *** [/home/jack/news/src/linux/linux-4.14.18/tools/build/Makefile.build:139: arch/x86] Error 2
make[2]: *** [Makefile:46: /home/jack/news/src/linux/linux-4.14.18/tools/objtool/objtool-in.o] Error 2
make[1]: *** [Makefile:62: objtool] Error 2
make: *** [Makefile:1632: tools/objtool] Error 2


After how many years during which we were vulnerable? :disappointed:

You probably needs elfutils-devel


I initially deleted the post because @cr6 has already spotted the right package, but to follow up on that briefly:

The error messages tell you which files are missing, and then you can use xlocate to track down the packages containing those files. In your case, it seems to be complaining about missing libelf.h and gelf.h. So:

$ xlocate -S
$ xlocate libelf.h
elfutils-devel-0.170_1  /usr/include/libelf.h
libphobos-2.077.0_2     /usr/share/doc/d/html/d/phobos/ddmd_libelf.html

and similarly

$ xlocate -S
$ xlocate gelf.h
elfutils-devel-0.170_1  /usr/include/gelf.h

That returns the package(s) containing the files you pass to xlocate. In this case the single package elfutils-devel provides both files.

(Edmond Dantes ) #4

Hi @jacksprat,

@grobber is right, more specifically you have to install libelf and elfutils-devel; moreover , in order to prevent further errors, since compile-script “extract-cert.sh” depends on header openssl/bio.h, you should install libressl-devel too, if you haven’t already

Best whishes


Thanks. “xlocate” is not a command on my machine, but I did install


Only then did the make proceed for kernel build [still going].

thanks, jacksprat


OK, xlocate is in the xtools package! Found this info on Steve Litt’s “Void Linux Tips” [troubleshooters.com].


Was it this link more precisely? That’ll make it easier to find.

Also, incidentally, xtools was mentioned in the wiki I linked to :slight_smile:

(Edmond Dantes ) #8

a couple of suggestions you may find useful:

  • Since I suppose you want to create a gzip/lzma/bzip2-compressed Linux image (vmlinuz) you need to run % make bzImage instead of bare % make (which will only create a vmlinux uncompressed image). make bzImage will create a compressed kernel image (named exacly bzImage) under $BUILD_DIR/arch/x86/boot, using the compression method you specified in your config. Now move it to your /boot directory, while renaming it properly:

% mv $BUILD_DIR/arch/x86/boot/bzImage /boot/vmlinuz-4.14.18

  • you don’t need to % make firmware, and copy it into /usr/lib, as void provides a linux-firmware multi-arch package which is rollling-updated and kernel release-independent

  • despite some guide may omit it, run % make modules before % make modules_install

  • when you export the kernel headers, use the classic linux location (/usr/src/include), like:

    % make headers_install ARCH=x86_64 INSTALL_HDR_PATH=/usr/src

It will create a folder named${INSTALL_HDR_PATH}/include. Now rename rename the include dir, following with the the void common notation, so as the final abosulute path is: /usr/src/kernel-headers-4.14.18.

Now, symlink it to your your kernel build direcory under modules:

ln -sf /usr/src/kernel-headers-4.14.18 /usr/lib/modules/4.14.18/build

Since make modules_install often symlinks your kernel build dir (the one containing your .config and vmlinuz) to /usr/lib/modules/uname -r/build, you can in this case copy the whole headers dir from /usr/src/… to your kernel build directory (which is suppose resides in your $HOME)

Finally remember to rebuild your initramfs:

cd /boot &&  dracut -f /boot/initrams-4.14.18.img 4.14.18

And update your grub config to make it detect both the new vmlinuz and initramfs:



Sorry, I was a bit lax with the reference.


Oh no worries, it was easily found, but it’s a bit out of date, so better stick with the wiki anyway: on my system the command xlocate -u (suggested on the troubleshooters website) will return

 xlocate: invalid option '-u'

Both the xtools man page and eyeballing the latest version of the xlocate script (at /usr/bin/xlocate on my system) indicate that the only accepted options currently are -g and -S.


[Montecristo] Thanks for the suggestions.

I tend to copy bzImage, .config and System.map to /boot with names that do not clash with the 4.14.18 kernel from the Void repos. I keep separate GRUB clauses for different ways of booting void and other distributions [devuan, salix, antix].

As a rule I actually pick up a blob-free kernel source tarball from linux-libre.fsfla.org, as I am not in love with [proprietary] firmware. In fact I was unhappy at the talk from Intel about their firmware solutions to the problems they created; so far I have not seen any need for this [but I wouldn’t know unless told].

The down side of my use of a custom module-free kernel is that I must add support for hardware that I previously removed by hand. I do like having a 6mb kernel and none of the 82mb of kernel modules that present a fat attack surface.

On initramfs, I try to use an alternative that I adapted from one at nairobi-embedded.org [though this site is no longer there]. All that is needed is a 120-line sh script and a few binaries abstracted from any decent distribution [I have used void and devuan]. All I need the initrd to do is run fsck.



Quick question Re: this

Seeing as you’re running plain make modules_install, have you guys ever run across the issue noted here of initramfs files growing out of hand because modules are not stripped?

I kept running out of space on a small boot partition because the modules weren’t stripped, so at some point resorted to doing

make INSTALL_MOD_STRIP=1 modules_install

instead. Perhaps it won’t matter much with a small enough kernel.


These packages are in the list of dependencies, see the template:wink:


Thanks. It would be an idea to create a dummy package, kernel-devel[-version], which would. when installed, drag all these in. Every distribution is different when it comes to the dependencies for building the kernel. Still, I should have found this site.



:man_cook: you can still create your own :cookie: dummy packages, it shouldn’t be that difficult…