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.