FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
659 views 11 comments
by anonymous

Hi,

I am using the latest SDK for TRB140 to compile a Firmware with glibc support, instead of musl. The make process always crashes with the error log attached below. Any suggestions how to solve the issue?

checking installed Linux kernel header files... 3.2.0 or later

checking for kernel header at least 4.14.0... too old!

configure: error: *** The available kernel headers are older than the requested

*** compatible kernel version

make[3]: *** [Makefile:31: /home/lauda/Documents/Original_libc/rutos-mdm9x07-trb1-gpl/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-8.4.0_glibc_eabi/glibc-2.33-headers/.configured] Error 1

make[3]: Leaving directory '/home/lauda/Documents/Original_libc/rutos-mdm9x07-trb1-gpl/toolchain/glibc/headers'

time: toolchain/glibc/headers/compile#1.90#2.13#8.84

    ERROR: toolchain/glibc/headers failed to build.

make[2]: *** [toolchain/Makefile:114: toolchain/glibc/headers/compile] Error 1

make[2]: Leaving directory '/home/lauda/Documents/Original_libc/rutos-mdm9x07-trb1-gpl'

make[1]: *** [toolchain/Makefile:110: /home/lauda/Documents/Original_libc/rutos-mdm9x07-trb1-gpl/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-8.4.0_glibc_eabi/stamp/.toolchain_compile] Error 2

make[1]: Leaving directory '/home/lauda/Documents/Original_libc/rutos-mdm9x07-trb1-gpl'

make: *** [/home/lauda/Documents/Original_libc/rutos-mdm9x07-trb1-gpl/include/toplevel.mk:234: world] Error 2

Hint: I followed the all instructions as described in the README.

1 Answer

0 votes
by anonymous
Hello,

Does it fail only when using glibc, or compiling sdk without any changes or other changes succeeds?

Regards,
VidasKac.
by anonymous

Hi,

compiling sdk without any changes works.

It works as well for minor changes, if I am selecting the libstdcpp (via make menuconfig - > Base system).

But it crashes when I am selcting glibc, instead of musl.

by anonymous

Hi,

Could you tell me what linux distribution you are using to compile SDK and output from command 

uname -a 

Best regards,
Vidas.

by anonymous

Hi,

Sorry for huged delayed answer, but the project was on hold.

In between I tried it as well with the newest SDK: TRB1_R_00.07.02.4 on different Virtual Machines:
1. Machine:
Linux ubuntu 5.13.0-40-generic #45~20.04.1-Ubuntu SMP Mon Apr 4 09:38:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
2. Machine:
Linux vm-rutossdk-dev-weu-001 5.15.0-1014-azure #17~20.04.1-Ubuntu SMP Thu Jun 23 20:01:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
For both machines I am not able to build a Firmware with glibc support. It always stops with the same error: "configure: error: *** The available kernel headers are older than the requested".

Do you have any suggestion to solve the issue?

by anonymous
checking installed Linux kernel header files... 3.2.0 or later
checking for kernel header at least 4.14.0... too old!

This SDK is build around a 3.18 kernel, far too old for a glibc 2.33 version.

I can't think of an easy workaround for the issue. Upgrading the kernel in target/linux/mdm9x07 would be a huge task (porting drivers hacking patches ...). Downgrading the glibc version itself may be doable the risk is that the compilation breaks later or worse that the generated executables won't run at all or just fail to perform their job.

Why do you want to replace musl by glibc ?

 
by anonymous

For one of our devices, we need to bring own Software to the Gateway to realize a IoT functionality with the Microsoft Azure. This Software requires the glibc to be executable.

Last time our Gateway Distributor created a “special” SDK (Version TRB1_R_GPL_00.07.00) with glibc support, together with your product support/RnD department. Due to your product change notification “Ethernet Transceiver chip change”, we are forced to a newer Firmware. That’s the reason why we do need a Firmware with glibc support.

In general, we want to be able to do it by ourselves in future. Is there any instruction available to create glibc Firmware out of your SDK? I already checked the Openwrt documentation/Forum, but unfortunately, I did not find anything related to it.

thx

by anonymous
If you still have this "special" SDK can you check the glibc version in toolchain/glibc/common.mk and the kernel version in target/linux/mdm9x07/Makefile ?
by anonymous

 toolchain/glibc/common.mk:

PKG_NAME:=glibc

PKG_VERSION:=2.27

PKG_SOURCE_PROTO:=git

target/linux/mdm9x07/Makefile:

include $(TOPDIR)/rules.mk

ARCH:=arm

BOARD:=mdm9x07

BOARDNAME:=Qualcomm MDM9x07

FEATURES:=squashfs fpu nand

CPU_TYPE:=cortex-a7

CPU_SUBTYPE:=neon-vfpv4

KERNEL_PATCHVER:=3.18

# hack for linux-msm 3.18 kernel

CONFIG_EXTERNAL_KERNEL_TREE:="$(TOPDIR)/target/linux/mdm9x07/src"

define Target/Description

Build firmware image for Qualcomm MDM9x07 SoC devices.

endef

by anonymous
Interesting.

What are the values of PKG_SOURCE_VERSION and PKG_MIRROR_HASH in toolchain/glibc/common.mk ?
by anonymous

PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)

PKG_SOURCE_VERSION:=daf88b1dd1a41fcb324801c02ead7a8d5aac3851

PKG_MIRROR_HASH:=fc78ef46c52c922ea44d079533d4d3017a0c921b4ed9aab8bb1dd071322b169f

PKG_SOURCE_URL:=https://sourceware.org/git/glibc.git

PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz

by anonymous
Maybe there is a path to success here. With this 2.27 version the first checks pass, but the process still fails during the "apply patches" phase. Could you execute tar cvfz glibcpatches.tar.gz toolchain/glibc/patches in this special SDK base folder and send me the file via PM ?
by anonymous
It is possible to get rid of the kernel 4.14 requirement while keeping the 2.33 version of glibc by editing toolchain/glibc/common.mk. glibc itself and most of the base openwrt packages will compile without hiccups. The few ones that don't will require some work.

Unfortunately the SDK contains several packages from Teltonika only available in executable / shared object / object file format which directly reference musl on some form or another. Those packages cannot be ported without access to the source code.

So the hypothetical "path to success" turns out to be a dead end.