Compilation issues

[maenpaa24]

Hello!

I used to build the source code from @r0m30 just substituting autoreconf with autoreconf -i in the builpbaroot and patching the m4 package with what is provided in this link: http://www.linuxfromscratch.org/lfs/view/development/chapter06/m4.html

On the other hand, when building this repo I also had to patch m4 and in addition subtituting https://git.busybox.net/buildroot variable with git://git.busybox.net/buildroot in the BUILDROOT variable from the conf file (otherwise git can not clone it). However it get stuck with this error:

xzcat /sedutil/images/scratch/buildroot/dl/linux-4.11.8.tar.xz | tar --strip-components=1 -C /sedutil/images/scratch/buildroot/64bit/build/linux-headers-4.11.8   -xf -
tar: drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c: Cannot open: Invalid argument
tar: drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h: Cannot open: Invalid argument
tar: include/soc/arc/aux.h: Cannot open: Invalid argument
tar: Exiting with failure status due to previous errors
make[1]: *** [package/pkg-generic.mk:164: /sedutil/images/scratch/buildroot/64bit/build/linux-headers-4.11.8/.stamp_extracted] Error 2
make: *** [Makefile:79: _all] Error 2

Could you help me?

By the way, I have also tried to substitute autoreconf with autoreconf -i in your buildpbaroot file with the same results. I have always used kali rolling for the compilation and for these latest tests I have reinstall kali to discard any issue.

Thanks.

[maenpaa24]

Well, I have got to the conclusion that the issue is because there are updated kernels and packages that are not completely backwards compatible. If you build sedutil on an older linux distribution it just works.

I don't know if I should close the issue. Building sedutil in a modern linux distribution has indeed two issues, which are related to building m4 and extracting linux-headers. The latter is pretty new, it started to happen at most three month ago while the former is a bit older (I think one year or more).

[ChubbyAnt]

@ladar what linux compilation environment have you confirmed working with your latest commits?

[ladar]

I'm not an Ubuntu fan, but ran into problems compiling on Arch and on CentOS 7, so I ended up using an Ubuntu 18.04 VM.

[ladar]

@ChubbyAnt @maenpaa24 I wasn't getting notifications of issues on this repo... I didn't realize I needed to "watch" my own repo for those.

Would a Vagrantfile which sets up a VM, and compiles the repo be of any use?

[ChubbyAnt]

@ladar @maenpaa24 I can confirm that the current commits compile successfully with Ubuntu 18.04.3.

[maenpaa24]

Yeah I remember starting to have issues in early 2019. So it sounds reasonable that it works on ubuntu 18.04. So great!

Regarding the vagrantfile for the vm, I think it could be really useful if one just wants to quickly build a rescue image, or even for further applications. So I would definitely say that it would be of use.

[oom-is]

Please see my pull request #306 against the vanilla DTA tree.
If ($someone) has the @ladar tree installed and applies those changes to use the more recent (supported/LTS) buildroot and kernel targets, then laterer OS releases Might Just Work.

A useful side effect is that all the other packages that Buildroot pulls in are also now using updated versions, with security fixes, etc.