[Question] How to compling extern kernel modules => "fixdep" elf in x86-64 ?

[wildcat_paris]

Hello Igor(?), Armbian Buddies,

 

I have ended being not able to compile a kernel module (and it breaks dkms btw) because files in linux-headers are ELF x86-64 (not ELF ARM) but it is quick & dirty FIXED :-)

 

(Maybe I have messed Armbian tool playing with v4.3 kernel ???)

root@bpi:~/kern4.3_4# dpkg -i linux-headers-next-sunxi_4.6_armhf.deb
Unpacking linux-headers-next-sunxi (4.6) over (4.6) ...
Setting up linux-headers-next-sunxi (4.6) ...

root@bpi:~/kern4.3_4# cd /usr/src/linux-headers-4.3.0-sunxi/scripts/basic/

root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/basic# file fixdep
fixdep: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=6852442a0a099c53c54516da788bcb41eb855d61, not stripped

root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/basic# uname -a
Linux bpi 4.3.0-sunxi #34 SMP Thu Nov 12 16:08:33 CET 2015 armv7l armv7l armv7l GNU/Linux

from Igor source  I thought it would be ok but nope

 

I ended getting this quick solution

root@bpi:/usr/src/linux-headers-4.3.0-sunxi# make scripts
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/bin2c
[...]

root@bpi:/usr/src/linux-headers-4.3.0-sunxi# file scripts/basic/fixdep
scripts/basic/fixdep: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=e21986187584d701fa8f4d5d987a9cee808208c8, not stripped

and of course

root@bpi:/usr/src/test# ls
hello-1.c  Makefile

root@bpi:/usr/src/test# make
make -C /lib/modules/4.3.0-sunxi/build M=/usr/src/test modules
make[1]: Entering directory `/home2/src/linux-headers-4.3.0-sunxi'
  CC [M]  /usr/src/test/hello-1.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/test/hello-1.mod.o
  LD [M]  /usr/src/test/hello-1.ko
make[1]: Leaving directory `/home2/src/linux-headers-4.3.0-sunxi'

root@bpi:/usr/src/test# insmod hello-1.ko

root@bpi:/usr/src/test# lsmod | grep hello
hello_1                  799  0

ok, as zador.blood.stained wrote about issue with builddeb => anything related I have a patching issue in "scripts" folder ?

root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/package# cat builddeb
builddeb       builddeb.orig  builddeb.rej

root@bpi:/usr/src/linux-headers-4.3.0-sunxi/scripts/package# cat builddeb.rej
--- scripts/package/builddeb
+++ scripts/package/builddeb
@@ -110,13 +112,17 @@
 BUILD_DEBUG="$(grep -s '^CONFIG_DEBUG_INFO=y' $KCONFIG_CONFIG || true)"

 # Setup the directory structure
-rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir" "$dbg_dir"
+rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir" "$dbg_dir" "$dtb_dir"
 mkdir -m 755 -p "$tmpdir/DEBIAN"
 mkdir -p  "$tmpdir/lib" "$tmpdir/boot" "$tmpdir/usr/share/doc/$packagename"
 mkdir -m 755 -p "$fwdir/DEBIAN"
 mkdir -p "$fwdir/lib/firmware/$version/" "$fwdir/usr/share/doc/$fwpackagename"
 mkdir -m 755 -p "$libc_headers_dir/DEBIAN"
 mkdir -p "$libc_headers_dir/usr/share/doc/$libc_headers_packagename"
+
+mkdir -m 755 -p "$dtb_dir/DEBIAN"
+mkdir -p "$dtb_dir/boot/dtb" "$dtb_dir/usr/share/doc/$dtb_packagename"
+
 mkdir -m 755 -p "$kernel_headers_dir/DEBIAN"
 mkdir -p "$kernel_headers_dir/usr/share/doc/$kernel_headers_packagename"
 mkdir -p "$kernel_headers_dir/lib/modules/$version/"

thanks!

 

Guillaume

 

PS: fyi, lamobo-r1 : sunxi-ss (kernel tests) & prng ok, AC97=> KO not recognized maybe DTB needs a fix

[zador.blood.stained]

I checked mine 4.3 headers, and fixdep arch is also x86_64. I extracted fixdep from Igor's 4.2.3 kernel packages, and its arch is ARM.

 

From what I read about fixdep, it is used by make and its arch should match host arch, so when we compile kernel on x86_64 Ubuntu, fixdep should have x86_64 arch too. I can only guess that packaging process is wrong and compiled binaries from scripts folder should not be packed into deb files.

Related bug report: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/666267

[wildcat_paris]

I checked mine 4.3 headers, and fixdep arch is also x86_64. I extracted fixdep from Igor's 4.2.3 kernel packages, and its arch is ARM.

 

From what I read about fixdep, it is used by make and its arch should match host arch, so when we compile kernel on x86_64 Ubuntu, fixdep should have x86_64 arch too. I can only guess that packaging process is wrong and compiled binaries from scripts folder should not be packed into deb files.

Related bug report: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/666267

 

thanks zador.blood.stained for digging launchpad

 

ok but Igor is using same Armbian build tool on x86_64 so that is strange.

gr@server1404:~/test_arch_scripts$ wget http://apt.armbian.com/pool/main/l/linux-upstream/linux-headers-next-sunxi_4.5_armhf.deb

gr@server1404:~/test_arch_scripts/usr/src/linux-headers-4.2.3-sunxi/scripts/basic$ file fixdep
fixdep: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=d7f63b82f3c7346453e5b3fea2fbcc3442132460, not stripped

FYI my guest running Ubuntu 14.04 server amd64 (GCC 4.8):

gr@server1404:~$ dpkg -l "*gnu*hf"

||/ Name                                    Version                  Architecture             Description
+++-=======================================-========================-========================-===================================================================================
ii  binutils-arm-linux-gnueabihf            2.24-5ubuntu13cross1.98. amd64                    GNU binary utilities, for arm-linux-gnueabihf target
ii  cpp-4.8-arm-linux-gnueabihf             4.8.2-16ubuntu4cross0.11 amd64                    GNU C preprocessor
ii  cpp-arm-linux-gnueabihf                 4:4.8.2-1                amd64                    The GNU C preprocessor (cpp) for armhf architecture
ii  gcc-4.8-arm-linux-gnueabihf             4.8.2-16ubuntu4cross0.11 amd64                    GNU C compiler
ii  gcc-4.8-multilib-arm-linux-gnueabihf    4.8.2-16ubuntu4cross0.11 amd64                    GNU C compiler (multilib files)
ii  gcc-arm-linux-gnueabihf                 4:4.8.2-1                amd64                    The GNU C compiler for armhf architecture

the following patch (comment #16 2011-12-27) makes the "make scripts" with CROSS_COMPILE (for arm instead of x86_64)

https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/666267/comments/16

 

so the "scripts" are needed in x86_64 format when building the kernel (as you wrote) on x86_64 Ubuntu

 

=> is there a kernel 4.2.x to 4.3.x problem? (just wondering as a newbie)

 

or a CROSS_COMPILE tool issue as, fixdep "file shows:

my Ubuntu 14.04 amd64 => armbian tool

fixdep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24

My lamobo-r1 local "make scripts"

fixdep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32

Igor Ubuntu 14.04 amd64 => armbian tool

fixdep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26

mine => GNU Linux 2.6.24 (from amd64) or 2.6.32 (from ARM)

Igor => GNU/Linux 2.6.26 (from amd64)

 

???

 

Or any missing cross tool Igor may have on his Ubuntu 14.04 amd64 that is not installed by the scripts ???

 

just in case I have added "multilib" cross tools then launched a "fresh" copy of Armbian and I get amd64,

 

so nothing related to 4.2/4.3 kernel

root@server1404:~/armb/output/debs/test_headers# cd usr/src/linux-headers-4.2.6-sunxi/scripts/basic/

root@server1404:~/armb/output/debs/test_headers/usr/src/linux-headers-4.2.6-sunxi/scripts/basic# file fixdep
fixdep: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=3de7788bd491d0c90d5dc137ede013d5ab8b9e27, not stripped

[Igor]

Here is my "secret" workaround

 

1. Rebuild inside chroot and repack.

https://github.com/igorpecovnik/lib/blob/second/boards.sh#L224

 

2. Before packing this patch is also needed - I do it within buildeb process:

https://github.com/igorpecovnik/lib/blob/second/patch/misc/headers-debian-byteshift.patch

 

I also needed few moments to recall how I solved this issue. 

 

Since kernel 4.3 has some changes within packaging process this workaround might stop working ...