On 7/23/2026 11:45 AM, Mohamed Mediouni wrote: > > >> On 10. Jul 2026, at 23:43, Pierrick Bouvier >> <[email protected]> wrote: >> >> Those options were useful a few years ago, before containers were >> available as an alternative for missing cross compilers. Simplify the >> workflow by removing those options and maintaining only the container >> based approach. >> >> Tested-by: Alex Bennée <[email protected]> >> Signed-off-by: Pierrick Bouvier <[email protected]> >> --- >> configure | 473 ------------------------------------------------------ >> 1 file changed, 473 deletions(-) >> > Hi, > > It’s nowhere near an upstream state, but we might want to consider some > architectures where Linux is not supported. > > An extreme example (which not remotely anywhere near going in tree yet): > there’s a working IA-64 system emulation tree around (on top of QEMU 11.0) > that can boot Windows and Linux guests. Linux and glibc do not have upstream > support anymore for that architecture. >
So you can probably build the "latest" version available, even if it means going back to debian last last last stable. In this case, we go back to "it works on my machine", and would be nice to make it work for anyone by doing the small effort to write a docker container for that. > aarch64_be might also be going that route in the not-too-far-away future... > > And there’s also macOS hosts and others, so while containers as a default > are very nice, there should still be an option to opt-out I think. > They are not mandatory, and I implemented the existing --disable-containers.
