Re: [PATCH v1 2/5] CI: drop Ubuntu 16.04

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.03.2026 10:29, Edwin Torok wrote:
> 
> 
>> On 31 Mar 2026, at 07:58, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 30.03.2026 18:17, Edwin Török wrote:
>>> Ubuntu 16.04 is EoL on 2026-04-02.
>>
>> It going EOL very soon is a good reason; it causing ...
>>
>>> It fails to build the emulator tests, probably due to a binutils that is 
>>> too old:
>>>
>>> ```
>>> gcc -m32 -march=i686 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall 
>>> -Wstrict-prototypes -Wno-unused-but-set-variable -Wno-unused-local-typedefs 
>>> -Werror -O2 -fomit-frame-pointer 
>>> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ 
>>> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -fno-pie 
>>> -fno-exceptions -fno-asynchronous-unwind-tables -ffreestanding -nostdinc 
>>> -I/builds/xen-project/people/edwintorok/xen/tools/tests/x86_emulator/../../../tools/firmware/include
>>>  -fno-stack-protector -g0 -D_16 -mpclmul -mssse3 -mpclmul -ffixed-xmm0 -Os 
>>> -DVEC_SIZE=16 -c ssse3-pclmul.c
>>> /tmp/cchhD6n5.s: Assembler messages:
>>> /tmp/cchhD6n5.s:202: Error: junk at end of line, first unrecognized 
>>> character is `{'
>>> /tmp/cchhD6n5.s:203: Error: junk at end of line, first unrecognized 
>>> character is `{'
>>> /tmp/cchhD6n5.s:205: Error: junk at end of line, first unrecognized 
>>> character is `{'
>>> ```
>>
>> ... build issues in the test blobs isn't. The harness is specifically able to
>> cope with blob build failures. Another thing would be if test_x86_emulator.c
>> failed to build (but see below).
> 
> The whole build pipeline failed, maybe I extracted the wrong part of the 
> error message.
> https://gitlab.com/xen-project/people/edwintorok/xen/-/jobs/13661296490
> 
> Unfortunately the output is truncated:
> ```
> Job's log exceeded limit of 4194304 bytes.
> Job execution will continue but no more output will be collected.
> ```

With that we of course can't find out what's wrong.

> It looks like GCC accepted the mavx512dq flag, but then binutils failed to 
> assemble the output?

But -mavx512dq would be passed only when building blobs, which ...

> Although as you say another way to avoid that would be to fix the gas version 
> check,
> more on that below.
> 
>>
>> Is the above representative output anyway (i.e. is this not perhaps 
>> interleaved
>> output from a parallel build)? ssse3-pclmul.c, built with -mssse3 -mpclmul 
>> (i.e.
>> no AVX512 options), shouldn't really involve `{'. Furthermore we specifically
>> have a check in the Makefile, skipping building altogether when gcc and/or 
>> gas
>> are too old.
>>
>>> Same test passes on Ubuntu 18.04.
>>
>> Hard to believe that there wouldn't be at least some failures. Perhaps said
>> check prevents the attempt to build the harness there?
> 
> The passing build logs are at 
> https://gitlab.com/xen-project/people/edwintorok/xen/-/jobs/13661296494/viewer
> There are failures about unrecognised compiler flags, which are indeed 
> ignored:
> ```
> gcc: error: unrecognized command line option '-mavx512fp16'; did you mean 
> '-mavx512f'?
> testcase.mk:16: recipe for target 'avx512fp16.bin' failed
> make[7]: *** [avx512fp16.bin] Error 1
> ```

... is tolerated to fail.

>>> Note: the minimum version of binutils might have to be updated.
>>> Ubuntu 16.04 had version 2.26.1, which satisfies the >= 2.25 requirement
>>> in the README, and yet it failed as shown above.
>>
>> The harness is special, as said. Imo we shouldn't be updating the 
>> requirements
>> just for it. If anything, the mentioned gcc/gas check may need updating. 
>> {evex},
>> for example, requires gas 2.29 (i.e. gcc6 time frame).
> 
> I think the problem might be that the checks aren’t done for the ‘run’ target 
> (which is what I’m attempting to use in the CI):
> ```
> # Suppress building by default of the harness if the compiler can't deal
> # with some of the extensions used. Don't alter the "run" target dependencies
> # though, as this target needs to be specified manually, and things may work
> # partially even with older compilers.
> 
> TARGET-y := $(TARGET)
> 
> ifneq ($(filter-out run% clean% distclean,$(MAKECMDGOALS)),)
> ```
> 
> The simplest solution here would be to remove ‘run%’ from the filter rules.

No, as said elsewhere, run% being different is intentional.

> If it is useful I can introduce an alias force-run, that can be used to 
> manually try to run anyway (although that attempt may in the end fail, as 
> with Ubuntu 16.04).
> What do you think?

Maybe. Or maybe we should have "check" targets alongside the "run" ones,
being aliases of one another perhaps for everything but the emulator
harness?

Jan