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: Arnd Bergmann <arnd at arndb dot de>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Neil MacLeod <glibc at nmacleod dot com>, libc-help at sourceware dot org
- Date: Tue, 19 Mar 2019 17:36:49 +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> <87zhpqu9a9.fsf@mid.deneb.enyo.de>
On Tue, Mar 19, 2019 at 5:19 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> > 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 */
>
> 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?
No, I'm still puzzled by this. linux/sysinfo.h should include
linux/types.h -> linux/posix_types.h -> asm/types.h -> asm-generic/types.h,
where this is defined.
With commit a623a7a1a567, we include linux/posix_types.h in a asm/socket.h,
where it was not included before, but nothing else changes.
If DllLibCurl.cpp includes sys/socket.h directly or indirectly before
sys/sysinfo.h, that would change the order in which the include guards
are processed, but should still not cause problems in theory.
Neil, can you send us the preprocessed source file? That might
give some hint about what order the files get included in and where
it does something unexpected.
Arnd