I’m trying to use a third-party service to manage some package installations, but it fail to build on the packet.net ARM v8 servers because of an architecture conflict. Was wondering if I could trick the command into thinking the build server was ARM v7 instead of ARM v8.
Here’s the details: I’m using platformio as a low-level build tool, and it’s trying to install packages like tool-bossac, but the only binaries available are for linux_armv6l, linux_armv7l, and linux_aarch64. I’ll be deploying these to a Raspberry Pi (so, linux_armv7l), but the build server is linux_armv8l, so the binaries aren’t found.
The compatibility search essentially relies on uname, so I should be able to trick it by adding RUN setarch armv7l INSTALL_CMD to my Dockerfile, but the only available architectures I’ve seen from setarch --list are uname26, linux32, linux64 and armv8l.
Is there a way I can trick my Dockerfile to thinking it’s armv7l so I can grab these binaries?
I’m a bit unclear what is getting the binaries here – is it platformio that is downloading them directly? Or are you pulling them in from a repository (through e.g. apt) in your Dockerfile?
If it’s platformio, I’d expect that there’s an environment variable that it should use to determine the architecture to use, overriding the detected one on the system.
Alternately, could you explicitly install the ARM v7 binaries in your Dockerfile and just call those directly?
It’s via platformio - using their package management system, which I don’t think can be configured via environment variables. I might just have to install the packages manually and create aliases for platformio. Thanks for the suggestion!
Hey @nckswt, just dropping into this thread to update you that the balena Native ARM builders now correctly identify their architecture as armv7l when building for the RPI3(release announcement), so you should now be able to build your project with out issue now.