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

[Edwin Torok <edwin.torok@xxxxxxxxxx>]

> 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.
```

It looks like GCC accepted the mavx512dq flag, but then binutils failed to 
assemble the output?
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
```

> 
>> 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.
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?

Best regards,
—Edwin
> As does VPCMPESTRIQ. I
> specifically have a local patch to make it possible to build the harness with
> pre-gcc7 (I don't have any gcc6 anywhere, to that boundary may be off by 1). I
> didn't think this hackery would be acceptable upstream.
> 
> Jan