This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: __kernel_long_t build failure with linux 5.1-rc1 - is this glibc related?
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Neil MacLeod <glibc at nmacleod dot com>
- Cc: libc-help at sourceware dot org, Arnd Bergmann <arnd at arndb dot de>
- Date: Tue, 19 Mar 2019 17:19:10 +0100
- Subject: Re: __kernel_long_t build failure with linux 5.1-rc1 - is this glibc related?
- References: <CAFbqK8=+0+TAYdz=xsLNAqT=J+SoCNxkEwxotP_h7pKwwDNTyA@mail.gmail.com>
* Neil MacLeod:
> I'm experiencing a build failure when building Kodi with linux 5.1-rc1
> and glibc-2.29 (gcc-8.3.0) for x86_64: http://ix.io/1DXy
>
> This is only an issue with 5.1-rc1, a git bisect of 5.0.2...5.1-rc1
> confirms the failure starts with the linux commit discussed here:
> https://lore.kernel.org/patchwork/patch/1049662/ (specifically, this
> commit: https://github.com/torvalds/linux/commit/a623a7a1a5670c25a16881f5078072d272d96b71)
>
> Is this now a glibc issue, or a problem with the 5.1-rc1 kernel? Or is
> the problem maybe elsewhere...?
This commit introduced a regression because it adds fds_bits and val
symbols to the global namespace, but this is a distinct issue.
> In file included from
> /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-next/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include/linux/kernel.h:5,
> from
> /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-next/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include/sys/sysinfo.h:24,
> from ../xbmc/platform/linux/PlatformDefs.h:44,
> from ../xbmc/XBDateTime.h:12,
> from ../xbmc/utils/StringUtils.h:35,
> from ../xbmc/utils/log.h:15,
> from ../xbmc/filesystem/DllLibCurl.cpp:13:
> /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-next/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include/linux/sysinfo.h:9:2:
> error: '__kernel_long_t' does not name a type; did you mean
> '__syscall_ulong_t'?
> __kernel_long_t uptime; /* Seconds since boot */
> ^~~~~~~~~~~~~~~
> __syscall_ulong_t
> /home/neil/projects/scratch/alternates/LibreELEC.tv/build.LibreELEC-Generic.x86_64-9.1-devel-next/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/include/linux/sysinfo.h:10:2:
> error: '__kernel_ulong_t' does not name a type; did you mean
> '__syscall_ulong_t'?
> __kernel_ulong_t loads[3]; /* 1, 5, and 15 minute load averages */
> ^~~~~~~~~~~~~~~~
> __syscall_ulong_t
This isn't a glibc header, it looks like the Linux UAPI header
<linux/sysinfo.h>.
I'm not sure why this triggers with commit a623a7a1a5670c25a16.
That looks entirely unrelated.
Arnd, any idea?