AGX Cross Compile Toolchain glibc version mismatch

So, I noticed the version of glibc that comes with L4T is 2.27, thus many system libraries are compiled against glibc 2.27.
While this works for most of things I’m compiling, I run into an issue when linking against certain system libraries since the linaro cross compiler (provided by NVIDIA in the downloads section) is using glibc 2.25. My develpoment setup is such that i pull off libraries i need during compile time from the target, this works most of the time except for a select few system libraries (such as libsystemd).

Is there a prebuilt cross compiler that is using glibc 2.27?
Am i essentially out of luck here? In the sense that I would be better off using crosstool-ng to create my own toolchain?

You could have found a legitimate issue, but I’m not sure if a minor release version would actually cause failure. You might want to give compile error details, and what it is you are compiling (if it is for example boot loader code which can be replicated, then there is a higher chance someone will know about the issue). There have been a number of cases where newer compilers will fail when working on the boot loader software, and perhaps there is some issue even in Linux user space, but more details will help.

So, its not bootloader code or anything. This is just some proprietary x86-64 software that I am porting to ARM. Generally, the compile errors i get are undefined references to GLIBC symbols. And since GLIBC version tags the symbols it exports, I will occasionally get “undefined reference @GLIBC_2.27” when i copy a system library from the jetson (specifically, to my x86 workstation (doing the cross compiling).

I’ll try to get a more concrete error later if necessary.

If a library of the wrong version is present, then you might see this. However, this tends to happen more often if the library is not even present. The specific error for “@GLIBC_2.27” might be due to specifying the release too specifically in the linking instructions even though any @GLIC_2" would work.

Which exact L4T release are you using (see “head -n 1 /etc/nv_tegra_release”)? What do you see from “dpkg -l | egrep "libc6"”?

It may be possible a symbolic link could work around the issue. What do you see from:
ldconfig -p | cut -d' ' -f1,3- | egrep -i 'libc[.]'

What do you see from:
ls -l /lib/aarch64-linux-gnu/libc.*

To be a bit more specific, it isn’t the compiler complaining about “@GLIBC_2.27”. This would be the linker, and the linker may be looking for this due to something in a compile setting (the error message is being passed through). In some cases any “libc-2.x” would work, although this isn’t guaranteed (which is fairly trivial to test…if it fails, then you can move on to more difficult fixes). What we can do is try to provide a symbolic link pretending to be GLIBC_2.27, but which is actually your existing aarch-linux-gnu version of libc.

Its R32, revision 3.1

The version of libc in /lib/aarch64-linux-gnu/ is 2.27.

in the Linaro cross compiler (on my x86 machine), the version of in /gcc-linaro-7.3.1/aarch64-linux-gnu/libc/lib/ is 2.25.

I’m trying to find a number of paths from the commands in the previous post:

Basically, it might be possible to use symbolic links in place and still have this work (which is easier and faster than any other solutions if it works), but knowing the paths of everything would be required. Actually building 2.25 for aarch64 is another path, but building glibc is not usually trivial (especially cross arch). Sometimes the minor release changes are still compatible, but software may not know this.

So, I ended up taking a similar approach to what you described, I ended up mounting the /lib/aarch64-linux-gnu directory from the jetson over sshfs to my cross compiliation box (this directory essentially only has the glibc libraries) and mounted it to my libc/lib folder inside the toolchain on my x86 machine. This seems to work fine without any issue (no runtime or compilation errors anymore). So it seems I may be good to go at this point. This environment is only temporary at this point until I get an actual arm workstation to compile.

I apologize for not getting you direct paths, I have to copy things over by hand since the machine in question isnt internet connected.
But on the Jetson, was pointing to (or something of that nature), the same thing for and others. (they were linked to their 2.27 counterparts. The same was true for the linaro toolchain (2.25 instead of 2.27). But after mounting the 2.27 libc to the toolchain, things seem to be working now.