Here is a simple "what I want to do".
I have C/C++ sources, some of which do NOT have dependencies outside of a stock RPi bullseye/bookworm image, and some which do (so they require libmosquitto installing, for example).
When I am doing native compilation, I have no problems, and no conceptual issue - I have the correct architecture shared libraries installed.
I can then take these binaries and move them to the same platform on the same architecture by copying the files (and ensuring that the runtime dependencies are also met) to the target.
If I build on armhf, I cannot move to the aarch64 platform, or vice versa.
The easiest thing would then be to do a native build on aarch64, and I now have two binaries, one for each architecture. This isn't intrinsically a problem, and doesn't require too much fiddling around on the target platform - again, nothing an 'apt install libxyz' can't resolve.
Now, as the owner of many bits of hardware, from ESP8266 modules, Pi Pico boards and so on, I am familiar with the idea of cross-targetting.
I compile using a specific toolchain and libraries to produce an executable that runs on the target hardware. Easy. Mostly because someone has done a lot of work setting stuff up (like the CMake rules, linker scripts, and all the minutiae that goes into turning my code into ones and zeros in a form some bit of silicon can use.
When I ask my friendly neighbourhood search engine, I find lots of "advice" about this, but I find that I am going around in circles, and keep bumping into the fact that things have changed since a post was made, or that it relies on the host machine running ubuntu or (insert condition here).
So, I am looking to keep things as simple as I can. I have CMakeLists.txt for my projects, I have a bunch of tool chains, and no real clue where to go from there.
Ideally, I would have one physical machine (Pi4) running the current latest version (bookworm aarch64) along with appropriate updates.
On this machine, I can develop and to an extent, debug my code, then when I am happy, I would like to build two variants, the armhf binaries, and the aarch64 binaries.
For ease of deployment in some cases, I would ideally be able to build "version-proof" binaries, so that they run on bullseye AND bookworm.
Apparently, this is possible by using the right toolchains (which I believe I have).
Is there a straight-forward guide to setting up such an environment that takes into account I may need things in addition to vanilla shared libraries. (For instance, I have a shared library in armhf/aarch64 flavours which isn't packaged) so that I can do what I want?
Back when I bought my first Pi (an original 256MB Model B), none of this was a worry, since it was 32 bit only. I have a number of Zero, Zero W and Pi2s, as well as later Model Bs, so going 64-bit only isn't really an option.
I have C/C++ sources, some of which do NOT have dependencies outside of a stock RPi bullseye/bookworm image, and some which do (so they require libmosquitto installing, for example).
When I am doing native compilation, I have no problems, and no conceptual issue - I have the correct architecture shared libraries installed.
I can then take these binaries and move them to the same platform on the same architecture by copying the files (and ensuring that the runtime dependencies are also met) to the target.
If I build on armhf, I cannot move to the aarch64 platform, or vice versa.
The easiest thing would then be to do a native build on aarch64, and I now have two binaries, one for each architecture. This isn't intrinsically a problem, and doesn't require too much fiddling around on the target platform - again, nothing an 'apt install libxyz' can't resolve.
Now, as the owner of many bits of hardware, from ESP8266 modules, Pi Pico boards and so on, I am familiar with the idea of cross-targetting.
I compile using a specific toolchain and libraries to produce an executable that runs on the target hardware. Easy. Mostly because someone has done a lot of work setting stuff up (like the CMake rules, linker scripts, and all the minutiae that goes into turning my code into ones and zeros in a form some bit of silicon can use.
When I ask my friendly neighbourhood search engine, I find lots of "advice" about this, but I find that I am going around in circles, and keep bumping into the fact that things have changed since a post was made, or that it relies on the host machine running ubuntu or (insert condition here).
So, I am looking to keep things as simple as I can. I have CMakeLists.txt for my projects, I have a bunch of tool chains, and no real clue where to go from there.
Ideally, I would have one physical machine (Pi4) running the current latest version (bookworm aarch64) along with appropriate updates.
On this machine, I can develop and to an extent, debug my code, then when I am happy, I would like to build two variants, the armhf binaries, and the aarch64 binaries.
For ease of deployment in some cases, I would ideally be able to build "version-proof" binaries, so that they run on bullseye AND bookworm.
Apparently, this is possible by using the right toolchains (which I believe I have).
Is there a straight-forward guide to setting up such an environment that takes into account I may need things in addition to vanilla shared libraries. (For instance, I have a shared library in armhf/aarch64 flavours which isn't packaged) so that I can do what I want?
Back when I bought my first Pi (an original 256MB Model B), none of this was a worry, since it was 32 bit only. I have a number of Zero, Zero W and Pi2s, as well as later Model Bs, so going 64-bit only isn't really an option.
Statistics: Posted by SteveSpencer — Fri May 03, 2024 4:19 pm