Linaro toolchain's Glib C version (2.25) does not match L4T_32.3.1 Glibc's version (2.27)

I’ve been cross compiling for the Jetson TX2 platform and I have found the following problem when compiling a program for Jetson TX2 which uses libcurl: Glibc’s version in the toolchain (2.25) does not match glibc’s version (2.27) shipped whit the latest Release ( L4T_32.3.1)

I’ve added to the toolchain all the libraries needed by the program (libcurl and all of its dependencies) and the linker failed to compile the program because two libraries were asking for functions not implemented in glibc 2.25 (tehu were asking for glibc 2.26 and glibc 2.27).
Checking the Glibc version installed on the board results in glibc 2.27.
I’ve checked if there is a newer linaro toolchain but the latest version (7.5) has also the glibc version 2.25.
In the arm developer page is released the9.2-2019.12 toolchain version but its based on the Glibc 2.30 or 2.31 (examining its manifestt is uses a glibc’s git tag which is between these two releases)
Toolchain’s manifest (only glibc’s part)

Component data for glibc

glibc_configure="–disable-profile --without-gd --enable-obsolete-rpc --with-headers=${sysroots}/usr/include libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes --without-selinux --disable-werror"

Which toolchain we have to use to be able to cross-compile for the latest L4T release (with Glibc 2.27)?

Thanks in advance
Best regards

One of the reasons I sometimes hate cross compile is the need for the user space libraries. One way to guarantee match, rather than providing runtime/sysroot libraries from a third party, is to mount a loopback clone of the Jetson itself, and use the clone’s content instead of a separately added runtime/sysroot.

Instructions for clone vary for different releases, but for the R32.x series you can clone from the “Linux_for_Tegra/” directory of the host PC via:
sudo ./ -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1

Be careful to have a lot of spare disk space prior to starting since this will produce two very large files. The first file is the “sparse” file, and this is good only for flash…I throw this file away, and this would be “my_backup.img”. The second file is the “raw” file, and this is very useful for all kinds of uses: “my_backup.img.raw”.

The raw file will the exact size of the entire root partition of the TX2 (about 30GB). The sparse file will be somewhere between a bit over a GB and the same size as the partition (the more empty space on the partition the smaller the sparse file, perhaps 2GB to 20GB). Simply delete the sparse file.

An example too loopback mount the raw clone on “/mnt”:
sudo mount -o loop ./my_backup.img.raw /mnt

Or to umount:

sudo umount /mnt

To mount read-only:
sudo mount -o loop,ro ./my_backup.img.raw /mnt

Then name this as your sysroot instead of the skeleton.

1 Like

Thanks for the help.
I’ve tried using as sysroot the rootfs of the board shared via NFS and mounted in the PC and a Image of the file system as sysroot (not generated in the same way as you - thanks for the instructions i’m pretty sure i will need them later).
In the case of Glibc, even if the correct version is in the sysroot or the toolchain libraries path, the linker fails because I think it tries to link against the glibc version that was used to generate the toolchain and not the one provided by the sysroot/toolchain’s library’s path. I do not know if i’m missing something.
SYSROOT shell variable is exported and points to the rootfs image/shared directory mounted in each case and I checked it has not been changed in the Makefiles of the program I’m compiling.

Thanks again for the help.
Best Regards

You are probably correct about the linker not liking the native library version in some cases. Linaro has had some ABI bugs in the past, and when an ABI is fixed, then earlier release libraries do not work correctly against the newer release binaries. I can’t say for sure this is the case for you, but it is possible. Do you have a full log available of the linker errors? It is possible that the issue is unrelated to the different versions and just shows up there as coincidence.

You could get the source code of the cross-linker and try to build a specific release again the loopback mounted clone libraries.

Incidentally, NFS can be a difficult way of doing things. A loopback mounted clone image is likely to have fewer headaches.