Re: __kernel_long_t build failure with linux 5.1-rc1 - is this glibc related?

[Neil MacLeod <glibc at nmacleod dot com>]

Many thanks Florian - I'll flag this up to Team Kodi and update the
mailing list if/when there is resolution.

Thanks again
Neil

On Tue, 19 Mar 2019 at 17:35, Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Neil MacLeod:
>
> > 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! :)
>
> No problem at all.
>
> I think I found the culprit:
>
> | /* put types of curl in namespace to avoid namespace pollution */
> | namespace XCURL
> | {
> | #define CURL CURL_HANDLE
> | #include <curl/curl.h>
> | #undef CURL
>
> <https://github.com/xbmc/xbmc/blob/master/xbmc/filesystem/DllLibCurl.h#L24>
>
> That is completely unsupportable, I'm afraid.
>
> What happens is that some headers get included, their include guards
> (preprocessor macros like __ASM_GENERIC_POSIX_TYPES_H) are set, but
> their definitions do not end up in the global scope.
>
> Subsequently in the compilation, the kernel headers are included
> again, but the include guard is present, so they do not provide the
> same definitions again (instead they expand to nothing at all).  This
> is why __kernel_long_t appears to be undefined the second time round.
>
> Kodi really has to stop doing this.  There is no way we keep
> compatibility with such header use.