wildcat_paris Posted November 15, 2015 Posted November 15, 2015 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 Posted November 15, 2015 Posted November 15, 2015 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 1
wildcat_paris Posted November 16, 2015 Author Posted November 16, 2015 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 Posted November 16, 2015 Posted November 16, 2015 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 ... 1
Recommended Posts