wildcat_paris Posted November 15, 2015 Share 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 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted November 15, 2015 Share 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 Link to comment Share on other sites More sharing options...
wildcat_paris Posted November 16, 2015 Author Share 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 Link to comment Share on other sites More sharing options...
Igor Posted November 16, 2015 Share 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 Link to comment Share on other sites More sharing options...
Recommended Posts