Issue in compiling nvidia-container-toolkit on meta-tegra jetpack 6.0 version

[rajeshkumarwr]

We are using meta-tegra R36.3.0 in our yocto layer, when we try to compile the nvidia-container-toolkit, we face the below build errors.
meta-tegra reference: https://github.com/OE4T/meta-tegra/commits?after=f873164fc3d4ee7f77b54d7b11d9abc96b3d38d0+69
For now, we are stick this version for our development.
Could you provide any suggestion to fix this issue? When i try to remove the macro "${GO_SRCURI_DESTSUFFIX}" from the recipe, I hit other issues.

Exception: bb.fetch2.FetchError: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export SSL_CERT_FILE="/jetpack6/bin/buildtools.buildtools-standalone-10.22.33.6b/sysroots/x86_64-wrlinuxsdk-linux/etc/ssl/certs/ca-certificates.crt"; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1762430130/bus"; export GIT_SSL_CAINFO="/jetpack6/bin/buildtools.buildtools-standalone-10.22.33.6b/sysroots/x86_64-wrlinuxsdk-linux/etc/ssl/certs/ca-certificates.crt"; export PATH="/jetpack6/build/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/jetpack6/layers/oe-core/scripts:/jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0/recipe-sysroot-native/usr/bin/aarch64-wrs-linux:/jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0/recipe-sysroot/usr/bin/crossscripts:/jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0/recipe-sysroot-native/usr/sbin:/jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0/recipe-sysroot-native/usr/bin:/jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0/recipe-sysroot-native/sbin:/jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0/recipe-sysroot-native/bin:/jetpack6/layers/oe-core/bitbake/bin:/jetpack6/build/tmp-glibc/hosttools:/jetpack6/layers/local/scripts"; export HOME="/folk/rramasam"; git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c core.pager=cat clone -n -s /jetpack6/build/downloads/git2/github.com.NVIDIA.nvidia-container-toolkit.git/ /jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0/${GO_SRCURI_DESTSUFFIX} failed with exit code 128, output:
fatal: destination path '/jetpack6/build/tmp-glibc/work/armv8a_tegra-wrs-linux/nvidia-container-toolkit/1.14.5-r0' already exists and is not an empty directory.

Thanks,
Rajesh

[madisongh]

That variable should be getting set in go.bbclass, per this OE-Core commit.

[dwalkes]

Looks like the underlying error is | /jetpack6/yocto/build/tmp-glibc/work/armv8a-wrs-linux/runc-docker/1.1.12+gitAUTOINC+a9833ff391-r0/temp/run.do_compile.2640366: line 166: cd: /jetpack6/yocto/build/tmp-glibc/work/armv8a-wrs-linux/runc-docker/1.1.12+gitAUTOINC+a9833ff391-r0/git/src/import: No such file or directory

Looks like what would happen if your work directory is in a bad state from a crash or build interruption. bitbake -c clean <failing recipe> is definitely the place to start if you haven't tried this yet. I'd do that for runc-docker and nvidia-container-toolkit

[rajeshkumarwr]

Hi @dwalkes
I am able to address the issue on runc-docker. Followed by there are other build failures, i couldn't figure out the Errors from the build log.
Pls find the attached log. Could you help here to find out the issue from the log?

nvidia-container-toolkit-log.do_compile.txt

Thanks
Rajesh

[rajeshkumarwr]

Hi @madisongh @dwalkes

Do you have any suggestion for the above comment?

Regards,
Rajesh

[madisongh]

A quick Google search on "golang exit code 2" - that exit code being the only error report I could see in your log file - indicates that something in the toolchain is reporting incorrect arguments being passed to it, or something along those lines. I'm not sure I can help any further... While styhead is the only branch I see that has nvidia-container-toolkit version 1.14.5, and support for that branch is more or less over with now, the last time we did run a build, it compiled fine.

So perhaps if you tried comparing a build using our demo distro against whatever layer set/build environment you're trying to put together, that might help? Otherwise, you might need to dig into some detailed debugging of your Go cross-build environment to see where that exit code is coming from.

[rajeshkumarwr]

Thanks @madisongh @dwalkes for the answers. I will check the toolchain of our build env.