Archlinux just updated gcc to 15.2.1+r604+g0b99615a8aef-1, and that
defaults now to GNU23 standard. This isn't what Xen codebase expects, for
example libxl fails to build with:

    libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
    libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
      447 |         endptr = strchr(str, '=');
          |                ^
    libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
      452 |         endptr = strchr(str, ',');
          |                ^
    libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
      454 |             endptr = strchr(str, 0);
          |                    ^
    libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
    libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
      447 |         endptr = strchr(str, '=');
          |                ^
    libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
      452 |         endptr = strchr(str, ',');
          |                ^
    libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
      454 |             endptr = strchr(str, 0);
          |                    ^
    cc1: all warnings being treated as errors

Specify GNU99 explicitly (same version as in the hypervisor, but the
GNU dialect), to fix the build, and avoid such surprises in the future.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
As discussed in v1, I'm changing the standard version for now. Note GCC
14 used to default to -std=gnu17, so that should work too, but keep it
consistent with the hypervisor.
The v1 that adjusted libxl can be used anyway, but it's less
backport-friendly.

Changes in v2:
- revert to old standard (specify it explicitly now), instead of
  adjusting the code to the new standard - this way is more
  backport-friendly
---
 tools/Rules.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index d9b9c740e964..de9100eb1681 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -38,6 +38,8 @@ ifeq ($(debug_symbols),y)
 CFLAGS += -g3
 endif
 
+CFLAGS += -std=gnu99
+
 ifneq ($(nosharedlibs),y)
 INSTALL_SHLIB = $(INSTALL_PROG)
 SYMLINK_SHLIB = ln -sf
-- 
2.51.0

On Fri, Feb 20, 2026 at 01:43:21AM +0100, Marek Marczykowski-Górecki wrote:
> Archlinux just updated gcc to 15.2.1+r604+g0b99615a8aef-1, and that
> defaults now to GNU23 standard. This isn't what Xen codebase expects, for
> example libxl fails to build with:
> 
>     libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
>     libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>       447 |         endptr = strchr(str, '=');
>           |                ^
>     libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>       452 |         endptr = strchr(str, ',');
>           |                ^
>     libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>       454 |             endptr = strchr(str, 0);
>           |                    ^
>     libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
>     libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>       447 |         endptr = strchr(str, '=');
>           |                ^
>     libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>       452 |         endptr = strchr(str, ',');
>           |                ^
>     libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>       454 |             endptr = strchr(str, 0);
>           |                    ^
>     cc1: all warnings being treated as errors
> 
> Specify GNU99 explicitly (same version as in the hypervisor, but the
> GNU dialect), to fix the build, and avoid such surprises in the future.
> 
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Hm, I should have tested it more precisely. This actually does not solve
the issue, it still fails to build on Arch. I did confirmed the
-std=gnu99 ended up in the relevant GCC call for libxl_cpuid.c.

So, I guess iterate on v1?

> ---
> As discussed in v1, I'm changing the standard version for now. Note GCC
> 14 used to default to -std=gnu17, so that should work too, but keep it
> consistent with the hypervisor.
> The v1 that adjusted libxl can be used anyway, but it's less
> backport-friendly.
> 
> Changes in v2:
> - revert to old standard (specify it explicitly now), instead of
>   adjusting the code to the new standard - this way is more
>   backport-friendly
> ---
>  tools/Rules.mk | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index d9b9c740e964..de9100eb1681 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -38,6 +38,8 @@ ifeq ($(debug_symbols),y)
>  CFLAGS += -g3
>  endif
>  
> +CFLAGS += -std=gnu99
> +
>  ifneq ($(nosharedlibs),y)
>  INSTALL_SHLIB = $(INSTALL_PROG)
>  SYMLINK_SHLIB = ln -sf
> -- 
> 2.51.0
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On 20.02.2026 01:56, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 20, 2026 at 01:43:21AM +0100, Marek Marczykowski-Górecki wrote:
>> Archlinux just updated gcc to 15.2.1+r604+g0b99615a8aef-1, and that
>> defaults now to GNU23 standard. This isn't what Xen codebase expects, for
>> example libxl fails to build with:
>>
>>     libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
>>     libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>>       447 |         endptr = strchr(str, '=');
>>           |                ^
>>     libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>>       452 |         endptr = strchr(str, ',');
>>           |                ^
>>     libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>>       454 |             endptr = strchr(str, 0);
>>           |                    ^
>>     libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
>>     libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>>       447 |         endptr = strchr(str, '=');
>>           |                ^
>>     libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>>       452 |         endptr = strchr(str, ',');
>>           |                ^
>>     libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>>       454 |             endptr = strchr(str, 0);
>>           |                    ^
>>     cc1: all warnings being treated as errors
>>
>> Specify GNU99 explicitly (same version as in the hypervisor, but the
>> GNU dialect), to fix the build, and avoid such surprises in the future.
>>
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> 
> Hm, I should have tested it more precisely. This actually does not solve
> the issue, it still fails to build on Arch. I did confirmed the
> -std=gnu99 ended up in the relevant GCC call for libxl_cpuid.c.

Is it possible that it's not so much the compiler, but glibc, which is the
problem here?

> So, I guess iterate on v1?

Perhaps. As per above it first needs to become clear where the issue is
actually coming from. Otoh making the code suitably C23-const-correct will
want to happen at some point anyway, I suppose.

Jan

On Fri, Feb 20, 2026 at 08:34:08AM +0100, Jan Beulich wrote:
> Is it possible that it's not so much the compiler, but glibc, which is the
> problem here?

Indeed, that's glibc. I tested it starting with CI container and updated
packages one by one - it's about glic 2.42 -> 2.43.

> > So, I guess iterate on v1?
> 
> Perhaps. As per above it first needs to become clear where the issue is
> actually coming from. Otoh making the code suitably C23-const-correct will
> want to happen at some point anyway, I suppose.

I'll sent v3 with remarks from your review on v1 applied.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

On 20/02/2026 10:10 am, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 20, 2026 at 08:34:08AM +0100, Jan Beulich wrote:
>> Is it possible that it's not so much the compiler, but glibc, which is the
>> problem here?
> Indeed, that's glibc. I tested it starting with CI container and updated
> packages one by one - it's about glic 2.42 -> 2.43.
>
>>> So, I guess iterate on v1?
>> Perhaps. As per above it first needs to become clear where the issue is
>> actually coming from. Otoh making the code suitably C23-const-correct will
>> want to happen at some point anyway, I suppose.
> I'll sent v3 with remarks from your review on v1 applied.
>

Agreed, the moment we limit tools to a specific std, we will fail to
find stuff like this.

In my copious free time, I keep on meaning to do one CI run with Xen
forced the the newest std too, so we can pick up fixes as we go rather
than finding them all in one go while trying to do something else in a
hurry.

~Andrew