Error during kernel cross-compilation

[Navee_nK]

Hi,

I have followed the steps outlined in this link: How to compile Linux Kernel Image and device tree using Yocto SDK to compile the kernel source. I was able to successfully execute up to the make imx_v8_defconfig step. However, when I run the next make command, I encounter the following errors.
CALL scripts/checksyscalls.sh
HOSTCC certs/extract-cert
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_rwlock_rdlock@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_setspecific@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_key_delete@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_rwlock_unlock@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlopen@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_rwlock_destroy@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlerror@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlclose@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dlsym@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_once@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_rwlock_wrlock@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_rwlock_init@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_key_create@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `pthread_getspecific@GLIBC_2.2.5'
/i.MX_93/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libcrypto.so: undefined reference to `dladdr@GLIBC_2.2.5'
collect2: error: ld returned 1 exit status
make[3]: *** [scripts/Makefile.host:114: certs/extract-cert] Error 1
make[2]: *** [scripts/Makefile.build:480: certs] Error 2
make[1]: *** [/i.MX_93/linux-imx/Makefile:1921: .] Error 2
make: *** [Makefile:234: __sub-make] Error 2

I have tried several workarounds and rebuilds, but none of them have resolved the issue. Could you kindly assist me in resolving this problem?

Note: I am using this kernel build for the i.MX93 EVK, and in Yocto, I have specified the machine config as imx93-11x11-lpddr4x-evk as menioned in the Yocto Project User's Guide.

Thanks,
Naveen

[Chavira]

Hi @Navee_nK!

Your Yocto SDK version is the same of the kernel that you want to compile?

I see that the error is on the crypto library so, you have to made the same modifications made in the kernel (standalone environment) in kernel compiled in the yocto sdk.

[Navee_nK]

Hi @Chavira ,

For yocto I am following this UG10164 i.MX Yocto Project User's Guide Rev. LF6.6.52_2.2.0 — 16 December 2024 and this is the kernel version I have cloned using the step given in this doc -
"repo init -u https://github.com/nxp-imx/imx-manifest
-b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml"

To build the Image and populate SDK, the steps followed are listed below:

Image:
$ DISTRO=fsl-imx-xwayland MACHINE=imx93-11x11-lpddr4x-evk source imx-setup-release.sh -b
build-xwayland
$ bitbake imx-image-full

Populate SDK: (Used the same environment with which I build the above Image)
$ DISTRO=fsl-imx-xwayland MACHINE=imx93-11x11-lpddr4x-evk bitbake imx-image-full -c populate_sdk

Then used the .sh file generated and executed it and sourced it in another environment and followed the below steps for Linux Kernel Standalone build:
$ git clone https://github.com/nxp-imx/linux-imx -b lf-6.6.y
$ cd linux-imx
$ make imx_v8_defconfig
$ make

Kindly let me know If I need to change anything from the above to solve the issue.

Thanks,
Naveen.

[Chavira]

Hi @Navee_nK!

Try cloning the exact kernel version of the Yocto SDK, in this case is 6.6.52.

Try using the next command:

$ git clone https://github.com/nxp-imx/linux-imx.git -b lf-6.6.52-2.2.0

Best Regards!

Chavira

[Navee_nK]

Hi @Chavira ,

Tried using the command you gave, but the same issue still exists.

Thanks,
Naveen

[Chavira · Accepted solution]

Hi @Navee_nK!

I have compiled the 6.6.52 kernel without errors.

I attached my log file of each step that I have followed.

[Navee_nK]

Hi @Chavira,

Thanks for the information. I will check it on my end.

Thanks,
Naveen

[jabck386]

Hi @Navee_nK 

we noticed the same issue but only have problems when using SDK on older Ubuntu 20.04.
SDK on Ubuntu 22.04 works as expected.

Were you maybe able to fix the issue?

[Navee_nK]

Hi @jabck386,

Yes, that was an issue on our end as well, and we were able to confirm it after @Chavira mentioned there was no problem with the SDK toolchain build. We then moved to a different PC with latest version of ubuntu, and that resolved the issue. Many thanks for confirming it on your end too, @jabck386 !