[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version



[CC += libc-alpha]

Hi glibc developers,

On 7/24/22 14:24, Aurelien Jarno wrote:
Hi,

On 2022-07-24 12:39, Alejandro Colomar (man-pages) wrote:
Hi Aurelien,

On 7/23/22 11:43, Aurelien Jarno wrote:
Hi,

On 2022-07-19 21:55, Alejandro Colomar wrote:
Package: libc6-dev
Version: 2.33-8
Severity: normal
X-Debbugs-Cc: alx.manpages@gmail.com


Hi,

We had a discussion in NGINX Unit about if we should use __NR_xxx
or SYS_xxx syscall numbers.  As maintainer of the Linux man-pages,
I suggested that we should use the libc macros (SYS_xxx), since
they are compatible with other non-Linux systems, and also because
they are the documented way for user space.  However, there was
some concern that someone might be running a new kernel with an
old glibc, and that __NR_xxx symbols might be available but not
SYS_xxx in that case.

Yes that sounds good.

Since the <bits/syscall.h> (included through <sys/syscall.h>)
header is generated automatically from the kernel headers at glibc
build time, Debian should make sure that the latest available
kernel headers are used, so building the latest Sid glibc package
should be done on a system with also the latest kernel available
in Sid, to have a complete SYS_xxx list.

This is basically what is done, the buildd chroots are updated twice a
week, so in the worst case glibc is build against a kernel headers
package that is 4 days old.

Is it?  I have kernel 5.18, but my bits/syscalls.h still says it was
generated from kernel 5.10 (that's a long time ago).  I have the latest Sid
packages for both the kernel and glibc.

Yes, this is definitely the case, glibc 2.33-8 has been built against
linux-libc-dev 5.18.5-1. What is wrong is "header is generated
automatically from the kernel headers at glibc build time". They are
generated by upstream at release time, not at build time.

Is there an easy way to regenerate that header to get the tatest syscalls? Maybe a command could be supplied so that users (or at least distributors) have it easy to regenerate them? Maybe it already exists but it's not widely known?

Cheers,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/


Reply to: