On 7/23/2026 8:55 AM, Alex Bennée wrote: > Pierrick Bouvier <[email protected]> writes: > >> On 7/20/2026 6:14 AM, Alex Bennée wrote: >>> Pierrick Bouvier <[email protected]> writes: >>> >>>> 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. >>> >> >> I was expecting some discussion around this patch, and to start it when >> the comment comes. Question is "Should we provide this feature or not?". >> I totally agree with you that we need to support other configurations we >> have in our CI, like MacOS and compilers from homebrew. >> >> However, instead of implementing this by keeping --cross-* options, I >> would be more keen to turn 'cc' into a list, instead of fixed choice. >> >> For instance, instead of: >> # tests/tcg/aarch64/meson.build >> tcg_tests += { >> 'aarch64-linux-user': { >> 'cc': 'aarch64-linux-gnu-gcc', >> ... >> >> We could have: >> tcg_tests += { >> 'aarch64-linux-user': { >> 'cc': ['aarch64-linux-gnu-gcc', 'some_other_variant-gcc'], >> ... > > The trouble is this will lead to quite a long list as every distro has > its own naming ABI. While Debian covers most things its not everything. >
The way I see it is that we offer native cross compilers (with a focus on debian at the moment), and the containerized ones: people have a choice. We can add any additional compiler name for other distros. Also, as Ilya mentioned before, cross compiler on fedora, for instance, are not providing any sysroot. So it makes them unusable in our case. So I'm not sure which other distro you would like to support that is not (alpine, arch, slack, other?). In all cases, just let me know what are your exact requirements (distro list and set of compilers) and I would be happy to make it work just as you expect on all those platforms. >> I think it's a saner choice, because one problem with --cross-* is that >> it allows people and maintainers to have their "own" setup, that are not >> documented anywhere. By forcing compilers to be added to dockerfiles and >> paths to be explicit in arch files, we make sure the same CI is >> reproducible for everyone. > > I agree the ideal is everything is dockerised for CI but there are times > its not practical: > > - working with very new features on bleeding edge compilers > - binary only toolchains for the more niche architectures > - unable to run any containers > - running the test inside containers (this is why > debian-all-test-cross has qemu-minimal pre-reqs) > The point of containerization is to hide those details in a reproducible recipe. For instance, we could definitely provide bleeding edge gcc to have the latest features. If test relies on a specific machine setup, it's basically dead code: CI and other devs can't run it. That's why containerization is important. >> A good example of that is xtensaeb, which was not in docker container >> file because it could be set with cross-cc-xtensaeb. > > I suspect it was more because its a niche of a niche of a > under-maintained port and it just hadn't been gotten round to. > >> >>> I'm confused here - I thought we wanted to keep local cross compilers >>> and provide containers as the fallback. Otherwise it will be very >>> difficult to test against newer compilers without having to rebuild the >>> containers. >>> >> >> That's exactly the point. By making it hard, you force by design things >> to be reproductible by anyone and documented. In this case, by forcing >> the people who wants a newer compiler to provide a dockerfile patch for it. >> >> Another example is the aarch64 test with have require a bleeding gcc-16. >> It's not even installable via debian repositories at the moment, it >> means the test is just always skipped in CI. So basically, it's not >> testing anything out of the original developer's machine who has the >> "right" setup. In this case, the right fix is not rely on latest gcc, >> but add manual the needed opcode so it works on any version (see patch >> included in current series). > > Hand coding the opcode will work for now, but eventually the gcc's will > be updated and we can generate from gcc. It's easier to extend tests > will inline assembly than hand encoding ops. > If you take some time and look at the patches, you'll see it adds all the needed infrastructure for when we'll have a gcc supporting it available in debian-all-test-cross container. So it's not a "will be like this forever", just the time people can access easily the right version. As mentioned above, until there, it's basically dead code: no one can run it. >> For those reasons, I'm really much more in favor to provide a default >> that works out of the box, instead of "it works on my machine with a >> custom configure option". > > I agree the default should be working out of the box but I still think > this is removing developer flexibility which will result in an up-front > barrier to getting tests in meaning they are just as likely not to get > written than the developer going through the process of working out how > to package the compiler. > This should be considered though. What's the point to add a test if dev doesn't want to commit providing recipe to build it also? "It works on a given machine" is the only thing we can ensure. Also, I would like to point that in all the 1500 tests, only 1 is concerned at the moment. I'm not sure we can call that a "general" need. It's a one line code change: https://lore.kernel.org/qemu-devel/[email protected]/ If we keep providing --cross-cc-arch options, we explicitly make sure people can keep on adding dead tests by design. Also, if I can help maintaining this, you know I'll be as reactive as I'm on other subsystems, and won't ignore an email asking for help to package anything. If it's still not convincing enough, let me know, and I'll add those features back. I made a good effort to address all requirements and remove any "implicit" aspect of our test suite. I would like to make this effort complete, thus why I insist in favor or removing it. What do you think? >> >>> Currently the MacOS build relies on local compilers built via brew. >>> >> >> Let me know which compiler is used on MacOS for cross compiling every >> arch, and I can add those to next version, so it can work out of the >> box. > > Cross compilers > aarch64 : aarch64-elf-gcc > i386 : i686-elf-gcc > > x86_64 : x86_64-elf-gcc > > I see our only usage of cross-prefix-X is for .gitlab-ci.d/macos.yml, so that should be easy to provide same feature, and extend it. I can add it by default in case you would reconsider your mind about --cross-cc-* options. > but brew also packages: > > arm-none-eabi-gcc > riscv64-elf-gcc > m68k-elf-gcc > > The arm one isn't being picked up at the moment, I need to debug that. > The other two aren't yet useful until we have system mode tcg tests for > those guests. > I think it needs to be added to .gitlab-ci.d/macos.yml also, because configure can't guess that by itself. >> >> Regards, >> Pierrick > Regards, Pierrick
