This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.31: hard freeze on Friday, 31st Jan
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Romain Naour <romain dot naour at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh at gotplt dot org>, GLIBC Devel <libc-alpha at sourceware dot org>, alistair23 <alistair23 at gmail dot com>
- Date: Sat, 01 Feb 2020 22:25:44 +0100
- Subject: Re: glibc 2.31: hard freeze on Friday, 31st Jan
- References: <78730bb4-4c3f-2cc6-bbdc-40ef1acfda27@gotplt.org> <19bcbe8f-8243-b98c-562d-aa0c19aa2ef2@gmail.com>
* Romain Naour:
> Hi All,
>
> Le 30/01/2020 à 16:15, Siddhesh Poyarekar a écrit :
>> Hi,
>>
>> It looks like testing during freeze has gone without incident and we're
>> nearing the release date. I'll begin release testing tomorrow, so
>> please do not commit anything after Friday noon UTC. That is, even if I
>> approve your patch for master and it fails to go in before noon UTC
>> tomorrow, it will have to wait until master reopens. NEWS patches are
>> an exception of course; I'll just fix up and commit if they are not
>> pushed in time when I review changes for more newsworthy items.
>>
>> If everything goes to plan, I will have finished release testing and cut
>> a release by Saturday night.
>
> The risc64 port needs at least a kernel headers >= 5.0
>
> Otherwise glibc fail to build with:
>
> ../sysdeps/unix/sysv/linux/riscv/rv64/arch-syscall.h:193:33: error: expected
> declaration specifiers or '...' before numeric constant
> 193 | #define __NR_riscv_flush_icache 259
> | ^~~
> In file included from ../sysdeps/unix/sysv/linux/riscv/flush-icache.c:25:
> /home/naourr/buildroot/test/toolchain/host/riscv64-buildroot-linux-gnu/sysroot/usr/include/asm/syscalls.h:29:36:
> error: unknown type name 'sys_riscv_flush_icache'
> 29 | __SYSCALL(__NR_riscv_flush_icache, sys_riscv_flush_icache)
> | ^~~~~~~~~~~~~~~~~~~~~~
>
> See: https://gitlab.com/kubu93/toolchains-builder/-/jobs/422726962
This is quite ocnfusing. Why doesn't expand __SYSCALL to nothing in
this context?
Ah, I see, this header wasn't originally written as a UAPI header.
Can you test if it works to drop these lines?
#if __has_include (<asm/syscalls.h>)
# include <asm/syscalls.h>
#else
# include <asm/unistd.h>
#endif
Including <sys/syscall.h> should now be sufficient.