Closed kekiefer closed 6 months ago
Unfortunately, we can't do this. That's a distro-wide setting, not per-machine.
It might be possible to make it tegra-specific by also modifying the glibc build so it's tegra-specific (and setting tegra-specific PACKAGE_ARCH for all its packages)... that might have some cascading effects on the build, though, and we might have to, at that point, make all userland packages tegra-specific.
We could at least document this issue, and advise folks to set OLDEST_KERNEL to 5.10 in their distro configurations.
Yeah, changing the PACKAGE_ARCH
of glibc does require anything that needs it to also share the same PACKAGE_ARCH
:
EXTRA_OECONF:append:tegra = " --enable-kernel=5.10"
PACKAGE_ARCH:tegra = "${TEGRA_PKGARCH}"
This failed as soon as glibc-locale
, and like you suspected that cascades.
In fact the build already contains a warning about this situation:
WARNING: linux-tegra-5.10.120+git-r0 do_configure: linux-tegra: OLDEST_KERNEL is "5.15" but the version of the kernel you are building is "5.10.120" - therefore glibc as built may not be compatible with this kernel. Either set OLDEST_KERNEL to an older version, or build a newer kernel.
I'm not sure how to move this forward short of adding some documentation and putting this in tegrademo. Is there anything else we can do? Having this global setting of OLDEST_KERNEL that will easily differ from what is available to machines, and can't be changed by machine layers, is quite a thorn.
I'm not sure how to move this forward short of adding some documentation and putting this in tegrademo.
I think that's about it, without getting possibly too clever.
Is there anything else we can do?
We could try setting TUNE_PKGARCH to ${TEGRA_PKGARCH} and OLDEST_KERNEL:tegra to 5.10 in tegra-common.inc. I think that would do the right thing. The drawback to that approach is that if you have a distro mixing tegras with other aarch64 targets, you'd end up building all the generic target packages twice - once for tegra and once for all the other aarch64 targets.
And I'm not sure how well that would play with some of the build-time stuff that runs under qemu. Hopefully it wouldn't break that.
Thanks for the suggestion. I think this approach makes sense in general, and it is working for my image build.
As of the nanbield release, OLDEST_KERNEL is set in meta.conf to version 5.15. This is newer than the version available to us for the tegra machines in the Jetpack 5 releases. As such, some components that use this variable (such as glibc) will be build assuming support for kernel features we don't have.
Override the OLDEST_KERNEL to 5.10, to match the linux-tegra kernel.
As for the particulars of why I did this, I noticed that some multithreaded applications would sporadically crash with the error
The futex facility returned an unexpected error code
. This was traced back to the use of a syscall that did not exist in 5.10: https://elixir.bootlin.com/glibc/glibc-2.38/source/nptl/futex-internal.c#L155 caused by the inappropriate setting ofOLDEST_KERNEL
at build time.Also applicable for Nanbield