Created attachment 96331 [details] config.log I'm compiling Mesa git with the following configure options: ./configure --prefix=/usr/xorg --libdir=/usr/xorg/lib64 --with-dri-drivers=i965 --with-gallium-drivers="" --enable-texture-float and I get the following error: make[4]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/egl/drivers/dri2' CC egl_dri2.lo In file included from ../../../../src/egl/main/egldriver.h:36:0, from egl_dri2.h:70, from egl_dri2.c:45: ../../../../src/egl/main/eglapi.h:126:90: warning: 'struct wl_resource' declared inside parameter list [enabled by default] typedef EGLBoolean (*QueryWaylandBufferWL_t)(_EGLDriver *drv, _EGLDisplay *displ, struct wl_resource *buffer, EGLint attribute, EGLint *value); ^ ../../../../src/egl/main/eglapi.h:126:90: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] egl_dri2.c: In function 'dri2_setup_screen': egl_dri2.c:507:27: error: 'EGL_OPENGL_ES3_BIT_KHR' undeclared (first use in this function) disp->ClientAPIs |= EGL_OPENGL_ES3_BIT_KHR; ^ egl_dri2.c:507:27: note: each undeclared identifier is reported only once for each function it appears in egl_dri2.c: In function 'dri2_create_context': egl_dri2.c:811:40: error: 'EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR' undeclared (first use in this function) && dri2_ctx->base.Profile == EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR) ^ egl_dri2.c:860:41: error: 'EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR' undeclared (first use in this function) if ((dri2_ctx->base.Flags & EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR) != 0 ^ egl_dri2.c:870:58: error: 'EGL_NO_RESET_NOTIFICATION_KHR' undeclared (first use in this function) if (dri2_ctx->base.ResetNotificationStrategy != EGL_NO_RESET_NOTIFICATION_KHR) { ^ Makefile:565: recipe for target 'egl_dri2.lo' failed make[4]: *** [egl_dri2.lo] Error 1 make[4]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/egl/drivers/dri2' Makefile:514: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/egl/drivers' Makefile:512: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/egl' Makefile:533: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src' Makefile:584: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 ********************* I attached config.log. Any hints?
Forget it! Error caused by old EGL header files installed. I just removed it and it compiled fine.
Created attachment 96363 [details] [review] egl: do not use system egl headers, make use of the one we provide Well this is kind of our fault as well. We should not be including the system headers, but the ones we provide. Feel free to give the patch a try.
(In reply to comment #2) > Created attachment 96363 [details] [review] [review] > egl: do not use system egl headers, make use of the one we provide > > Well this is kind of our fault as well. We should not be including the > system headers, but the ones we provide. > > Feel free to give the patch a try. Hi Emil. I tried your patch and it didn't work. If you want to test yourself there, just put some old Mesa 8.0.5 header files in /usr/xorg/include/EGL (or whatever you use): eglext.h egl.h eglmesaext.h eglplatform.h But it's nice to see this will change, because I thought it was very strange for Mesa to use the system header files. Thank you very much! Ps: I think this change will have to be made for GL header files too, because I had to remove the GL system header files otherwise it would give errors. Ps2: if you want me to test other patch, just ask.
Seems like gcc does not handle include directives as I though it would. The only difference quoted vs angle brackets make is an extra searches for the header in the folder containing the source file. One can prevent from searching the default locations using -nostdinc, although that should not be required. Dâniel I'm kind of struggling to see(tested as well) how on earth did the system header got included in your case, pending any funny options during the compilation of gcc (other pieces of the toolchain). -I$(top_srcdir)/include is used prior to any other, which should handle things correctly.
(In reply to comment #4) > Dâniel I'm kind of struggling to see(tested as well) how on earth did the > system header got included in your case, pending any funny options during > the compilation of gcc (other pieces of the toolchain). > > -I$(top_srcdir)/include is used prior to any other, which should handle > things correctly. Hmmm I have the following CPPFLAGS system-wide: -I/usr/xorg/include -I/usr/local/BerkeleyDB/include As far as I remember, some software I tried to compile had trouble to find the header files. Even with CPPFLAGS set, Mesa should look for their own header files first? Or not? At least here it seems CPPFLAGS will be at the end: http://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html I ran configure *without* CPPFLAGS and it worked (without your patch). So the problem is CPPFLAGS. The problem is: configure accepts CPPFLAGS. Does it mean that when CPPFLAGS is set it has precedence over Mesa include paths or no? Or Mesa should put CPPFLAGS *after* their own include paths? Maybe this would avoid this problem when user sets CPPFLAGS?
(In reply to comment #5) > Or Mesa should put CPPFLAGS *after* their own include paths? Maybe this > would avoid this problem when user sets CPPFLAGS? If the user sets his own CPPFLAGS, he gets whatever is the result.
(In reply to comment #5) > Hmmm I have the following CPPFLAGS system-wide: > > -I/usr/xorg/include -I/usr/local/BerkeleyDB/include > A crucial piece of information you could have mentioned earlier :) > As far as I remember, some software I tried to compile had trouble to find Report a bug with them and drop this gross hack, please. [...] > Or Mesa should put CPPFLAGS *after* their own include paths? Maybe this > would avoid this problem when user sets CPPFLAGS? As Matt hinted, mesa is not to blame about "I'm using this hack as some other software needed it". If you have to use such workarounds use a more appropriate solution :P [1] [1] http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
(In reply to comment #7) > A crucial piece of information you could have mentioned earlier :) I completely forgot it ;) Sorry. > As Matt hinted, mesa is not to blame about "I'm using this hack as some > other software needed it". If you have to use such workarounds use a more > appropriate solution :P [1] > > [1] http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html Ok. I'll remove that. Thank you both ;)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.