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?
Hi Arnd
I've enabled -save-temps on gcc and uploaded
http://milhouse.libreelec.tv/other/DllLibCurl.ii (2MB file) - is this
what you are after?
This is a link to the Kodi source code:
https://github.com/xbmc/xbmc/blob/master/xbmc/filesystem/DllLibCurl.cpp
@florian apologies if this isn't a glibc issue, at times like this I'm
a bit out of my comfort zone/depth! :)
Regards
Neil
On Tue, 19 Mar 2019 at 16:37, Arnd Bergmann <arnd@arndb.de> wrote:
>
> 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