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.
> 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)
> 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.
> 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.
>
> 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
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.
>
> Regards,
> Pierrick
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
