pbuilder gets confused installing to target in cross-compilation environment

[udance4ever]

build is chugging along pretty well. occasionally, pbuilder gets its wires crossed in cross-compilation environments with a few packages:

ERROR: architecture for "/usr/bin/zstd" is "AArch64", should be "Advanced Micro Devices X86-64"
ERROR: architecture for "/usr/lib/libzstd.so.1.5.5" is "AArch64", should be "Advanced Micro Devices X86-64"
ERROR: architecture for "/usr/lib/libzstd.a" is "AArch64", should be "Advanced Micro Devices X86-64"
make[2]: *** [package/pkg-generic.mk:401: /x86_64/build/zstd-1.5.5/.stamp_installed] Error 1
make[1]: *** [Makefile:23: _all] Error 2
make[1]: Leaving directory '/x86_64'

zstd.log

workaround is to delete build directory and rebuild & reinstall target outside of pbuilder:

squatter@lina:~/dev/parallel2$ make x86_64-shell
squatter@b80a24f3b9f1:/x86_64$ make zstd

4 packages impacted in Batocera Linux v41-dev build that may help identify a pattern:

1. tar
2. zstd
3. xlib_libfontenc
4. vim - also a good example of a build that doesn’t know how to deal with a failed install (ie. have to manually delete symlinks: target/usr/bin/{view, vimdiff, rview, ex} to get install_target to complete)

[udance4ever]

found 2nd class of target install error where a required header file (jpeglib.h) from package jpeg-turbo was missing in target (thus package grim fails)

1. jpeg-turbo

workaround is the same: build package outside of pbuilder environment and resume pbuild afterwards.

[paguilar]

This could also be related to what I mentioned in this comment in #4 . It takes time to debug since it doesn't happen always and when it happens it could be with different packages. Anyway I'm analyzing it to try to find out the issue.

[udance4ever]

I found a package whose error appears to be reproducible (libvpx) during a bcm2836 clean build:

Error opening config file ‘/bcm2836libs-generic-gnu.mk`: No such file or directory

the file exists at:

/bcm2836/build/libvpx-1.13.1/libs-generic-gnu.mk

so something is getting lost in translation as /build/libvpx-1.13.1/ is missing from the path name.

Since this package (libvpx) appears to more reliably trigger a bug, it might be worth focusing on?

libvpx.log.gz