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

[Neil MacLeod <glibc at nmacleod dot com>]

I've opened an issue with Kodi: https://github.com/xbmc/xbmc/issues/15775

If anyone wishes to chime in on the issue with suggestions, please do
- this might be a good opportunity to address header misuse, in case
Team Kodi are not aware of the issues.

Regards
Neil

On Tue, 19 Mar 2019 at 17:44, Neil MacLeod <glibc@nmacleod.com> wrote:
>
> 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.