Kodi Community Forum

Full Version: Build failure of 18.4
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I am experiencing a build error under Arch Linux when building kodi-x11 18.4.

Link entire build log.  If I grep the relevant lines out of that log:
Code:
[ 86%] Building CXX object build/cores/VideoPlayer/subtitles/CMakeFiles/dvdsubtitles.dir/DVDSubtitleStream.cpp.o
In file included from /build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.h:14,
                 from /build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp:9:
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/VaapiEGL.h:38:3: error: ‘PFNGLEGLIMAGETARGETTEXTURE2DOESPROC’ does not name a type; did you mean ‘PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC’?
   38 |   PFNGLEGLIMAGETARGETTEXTURE2DOESPROC glEGLImageTargetTexture2DOES;
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |   PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp: In member function ‘virtual bool CRendererVAAPI::Configure(const VideoPicture&, float, unsigned int)’:
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp:84:13: error: ‘struct VAAPI::InteropInfo’ has no member named ‘glEGLImageTargetTexture2DOES’
   84 |     interop.glEGLImageTargetTexture2DOES = (PFNGLEGLIMAGETARGETTEXTURE2DOESPROC)eglGetProcAddress("glEGLImageTargetTexture2DOES");
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp:84:45: error: ‘PFNGLEGLIMAGETARGETTEXTURE2DOESPROC’ was not declared in this scope; did you mean ‘PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC’?
   84 |     interop.glEGLImageTargetTexture2DOES = (PFNGLEGLIMAGETARGETTEXTURE2DOESPROC)eglGetProcAddress("glEGLImageTargetTexture2DOES");
      |                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                             PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC
[ 86%] Building CXX object build/utils/CMakeFiles/utils.dir/SortUtils.cpp.o
make[2]: *** [build/cores/VideoPlayer/videorenderers/hwdec/CMakeFiles/videorenderers_hwdec.dir/build.make:63: build/cores/VideoPlayer/videorenderers/hwdec/CMakeFiles/videorenderers_hwdec.dir/RendererVAAPIGL.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:10128: build/cores/VideoPlayer/videorenderers/hwdec/CMakeFiles/videorenderers_hwdec.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Perhaps some incompatibility with latest mesa or the like?

Here is my cmake stanza:
Code:
  cmake -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=/usr/lib \
    -DENABLE_EVENTCLIENTS=ON \
    -DENABLE_INTERNAL_FFMPEG=ON \
    -DENABLE_INTERNAL_FMT=ON \
    -DENABLE_INTERNAL_CROSSGUID=ON \
    -DENABLE_INTERNAL_FSTRCMP=ON \
    -DENABLE_INTERNAL_FLATBUFFERS=ON \
    -Dlibdvdcss_URL="/kodi-libdvdcss-1.4.2-Leia-Beta-5.tar.gz" \
    -Dlibdvdnav_URL="/kodi-libdvdnav-6.0.0-Leia-Alpha-3.tar.gz" \
    -Dlibdvdread_URL="/kodi-libdvdread-6.0.0-Leia-Alpha-3.tar.gz" \
    -DFFMPEG_URL="/kodi-ffmpeg-4.0.4-Leia-18.4.tar.gz" \
    -DFMT_URL="/kodi-fmt-5.1.0.tar.gz" \
    -DCROSSGUID_URL="/kodi-crossguid-8f399e8bd4.tar.gz" \
    -DFSTRCMP_URL="/kodi-fstrcmp-0.7.D001.tar.gz" \
    -DFLATBUFFERS_URL="/kodi-flatbuffers-1.9.0.tar.gz" \
    ../"xbmc-18.4-Leia"
  make
  make preinstal
Make sure: GL_GLEXT_PROTOTYPES is properly defined then gl.h will pull above symbols in. Please check with the arch guys about your mesa build flags.
(2019-10-19, 15:56)graysky Wrote: [ -> ]I am experiencing a build error under Arch Linux when building kodi-x11 18.4.

Link entire build log.  If I grep the relevant lines out of that log:
Code:
[ 86%] Building CXX object build/cores/VideoPlayer/subtitles/CMakeFiles/dvdsubtitles.dir/DVDSubtitleStream.cpp.o
In file included from /build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.h:14,
                 from /build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp:9:
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/VaapiEGL.h:38:3: error: ‘PFNGLEGLIMAGETARGETTEXTURE2DOESPROC’ does not name a type; did you mean ‘PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC’?
   38 |   PFNGLEGLIMAGETARGETTEXTURE2DOESPROC glEGLImageTargetTexture2DOES;
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |   PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp: In member function ‘virtual bool CRendererVAAPI::Configure(const VideoPicture&, float, unsigned int)’:
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp:84:13: error: ‘struct VAAPI::InteropInfo’ has no member named ‘glEGLImageTargetTexture2DOES’
   84 |     interop.glEGLImageTargetTexture2DOES = (PFNGLEGLIMAGETARGETTEXTURE2DOESPROC)eglGetProcAddress("glEGLImageTargetTexture2DOES");
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/build/kodi/src/xbmc-18.4-Leia/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/RendererVAAPIGL.cpp:84:45: error: ‘PFNGLEGLIMAGETARGETTEXTURE2DOESPROC’ was not declared in this scope; did you mean ‘PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC’?
   84 |     interop.glEGLImageTargetTexture2DOES = (PFNGLEGLIMAGETARGETTEXTURE2DOESPROC)eglGetProcAddress("glEGLImageTargetTexture2DOES");
      |                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                             PFNGLEGLIMAGETARGETTEXTURESTORAGEEXTPROC
[ 86%] Building CXX object build/utils/CMakeFiles/utils.dir/SortUtils.cpp.o
make[2]: *** [build/cores/VideoPlayer/videorenderers/hwdec/CMakeFiles/videorenderers_hwdec.dir/build.make:63: build/cores/VideoPlayer/videorenderers/hwdec/CMakeFiles/videorenderers_hwdec.dir/RendererVAAPIGL.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:10128: build/cores/VideoPlayer/videorenderers/hwdec/CMakeFiles/videorenderers_hwdec.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Perhaps some incompatibility with latest mesa or the like?

Here is my cmake stanza:
Code:
  cmake -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=/usr/lib \
    -DENABLE_EVENTCLIENTS=ON \
    -DENABLE_INTERNAL_FFMPEG=ON \
    -DENABLE_INTERNAL_FMT=ON \
    -DENABLE_INTERNAL_CROSSGUID=ON \
    -DENABLE_INTERNAL_FSTRCMP=ON \
    -DENABLE_INTERNAL_FLATBUFFERS=ON \
    -Dlibdvdcss_URL="/kodi-libdvdcss-1.4.2-Leia-Beta-5.tar.gz" \
    -Dlibdvdnav_URL="/kodi-libdvdnav-6.0.0-Leia-Alpha-3.tar.gz" \
    -Dlibdvdread_URL="/kodi-libdvdread-6.0.0-Leia-Alpha-3.tar.gz" \
    -DFFMPEG_URL="/kodi-ffmpeg-4.0.4-Leia-18.4.tar.gz" \
    -DFMT_URL="/kodi-fmt-5.1.0.tar.gz" \
    -DCROSSGUID_URL="/kodi-crossguid-8f399e8bd4.tar.gz" \
    -DFSTRCMP_URL="/kodi-fstrcmp-0.7.D001.tar.gz" \
    -DFLATBUFFERS_URL="/kodi-flatbuffers-1.9.0.tar.gz" \
    ../"xbmc-18.4-Leia"
  make
  make preinstal

With glvnd 1.2.0 and mesa 19.2, mesa no longer ships the headers. glvnd does.

Nevermind on the missing. It's in the GLES glext.h. Check packing on the new glvnd due to the change.
Hmm, empty platform looks suspicious:
Code:
-- Core system type: linux
-- Platform:
-- CPU: x86_64, ARCH: x86_64-linux

Try forcing core_platform and gfx api
Code:
-DENABLE_OPENGL=ON -DENABLE_OPENGLES=ON -DCORE_SYSTEM_NAME=linux -DCORE_PLATFORM_NAME=x11

Edit: ouch, I didn't see the glvnd line, cmake vars above probably won't help.
(2019-10-19, 16:12)asavah Wrote: [ -> ]Edit: ouch, I didn't see the glvnd line, cmake vars above probably won't help.
https://www.archlinux.org/packages/extra...vnd/files/

The arch package is missing the entire usr/include/GLES/ directory. It looks like that's intentional on Arch's part. They're buildling without GLESv1. It should be grabbing it from GLES2/gl2ext.h
Why are they doing it? Breaking backwards compatibility just cause they can?
(2019-10-19, 16:38)yasij Wrote: [ -> ]The arch package is missing the entire usr/include/GLES/ directory. It looks like that's intentional on Arch's part. They're buildling without GLESv1. It should be grabbing it from GLES2/gl2ext.h 

That's not the problem.
The problem is that arch is shipping includes from glvnd, which don't have the needed defines, and not from mesa.
LibreELEC does the opposite: they build glvnd with --without-headers and ship mesa includes.

Anyway thats arch packaging bug and should be addressed by arch mantainers.

On sidenote: did anyone expect anything good coming from NVIDIA https://github.com/NVIDIA/libglvnd  Rofl
Thanks for all the quick replies.  In short, I want to verify what needs to be fixed on my system and then open the report for Arch upstream.

Here is what I see affecting libglvnd and mesa from Arch:
For libglvnd: it looks like this recent change to libglvnd includes an upstream patch to disable glesv1 or v2 and compiles with the --disable-gles1 switch.
For mesa: it looks like this modified the package to stop providing headers since the libglvnd package provides them.

1) Is the proposed culprit is solely libglvnd or both libglvnd + mesa?
2) What is the proposed fix/fixes?

Thanks!
One thing is open and the other one is yet another nvidia thingy ...

Remove the nvidia thingy and stop patching upstream mesa
AFAIK disabling gles1 is irrelevant.

I'm not distro/packaging expert but this is how I see it:
1) the culprits are bandwagoning arch maintainers  Tongue,not the packages themselves, I guess that they updated mesa with that patch but didn't bother to check if anything dependent on mesa headers at buildtime broke, I guess Kodi is not the only package that broke, nothing new, usual arch way.
2) it's up to the maintainers to decide, as I see it: either disable glvnd headers and ship mesa's or patch glvnd headers to provide missing stuff.
Thanks for the feedback, all: https://bugs.archlinux.org/task/64182
(2019-10-19, 20:41)asavah Wrote: [ -> ]AFAIK disabling gles1 is irrelevant.

I'm not distro/packaging expert but this is how I see it:
1) the culprits are bandwagoning arch maintainers  Tongue,not the packages themselves, I guess that they updated mesa with that patch but didn't bother to check if anything dependent on mesa headers at buildtime broke, I guess Kodi is not the only package that broke, nothing new, usual arch way.
2) it's up to the maintainers to decide, as I see it: either disable glvnd headers and ship mesa's or patch glvnd headers to provide missing stuff.

They didn't patch Mesa. Mesa 19.2 no longer ships the headers when built with glvnd 1.2.0. This was a decision by Mesa upstream. They decided that glvnd should really be shipping the headers, not Mesa.

The official Khronos headers have PFNGLEGLIMAGETARGETTEXTURE2DOESPROC defined in GLES/glext.h and GLES2/gl2ext.h since it is part of the GL_OES_EGL_image OpenGLES extension. I don't it's necessarily wrong that it's missing from the glvnd version of gl.h. It's in their GLES/glext.h and GLES2/gl2ext.h.
(2019-10-19, 17:25)asavah Wrote: [ -> ]On sidenote: did anyone expect anything good coming from NVIDIA https://github.com/NVIDIA/libglvnd  Rofl 
Nvidia may have originally created it, but it's now been moved to freedesktop:
https://gitlab.freedesktop.org/glvnd/libglvnd
(2019-10-19, 23:44)yasij Wrote: [ -> ]They didn't patch Mesa. Mesa 19.2 no longer ships the headers when built with glvnd 1.2.0. This was a decision by Mesa upstream. They decided that glvnd should really be shipping the headers, not Mesa. 

Technically they did - they brought in a patch from mesa git which is not present in 19.2.1 release. https://git.archlinux.org/svntogit/packa...kages/mesa
(2019-10-19, 23:52)yasij Wrote: [ -> ]
(2019-10-19, 17:25)asavah Wrote: [ -> ]On sidenote: did anyone expect anything good coming from NVIDIA https://github.com/NVIDIA/libglvnd  Rofl 
Nvidia may have originally created it, but it's now been moved to freedesktop:
https://gitlab.freedesktop.org/glvnd/libglvnd 
I'm aware of that, but AFAIK it's purpose is to "seemlessly" switch between GL implementations, which again AFAIK in x86 world is needed mostly for easier nvidia proprietary blobs integration within distro.
Pages: 1 2