| Summary: | dev-libs/efl-1.21.1-r3 fails to crosscompile: ../src/lib/evas/Evas_GL.h:4276:19: error: conflicting types for ‘GLintptr’ | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thomas Sachau <tommy> |
| Component: | Current packages | Assignee: | Joonas Niilola <juippis> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | cross, duncan, jstein, leio |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log on amd64 for ABI=x86 | ||
|
Description
Thomas Sachau
2019-01-11 18:51:30 UTC
I have to correct myself: This issue happens with USE=opengl, with that flag disabled the package builds just fine. What mesa version is this? There was a problem with including both opengl and gles2 headers on 32bit systems, but should be fixed in mesa-18.2.5 and any 18.3. That said - if efl has an at-most-one-of rule on gles2 vs opengl, then why does such an inclusion of both headers happen? If that's the problem here at all, that is. https://bugs.freedesktop.org/show_bug.cgi?id=105328 https://github.com/KhronosGroup/OpenGL-Registry/issues/162 emerge -pv mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-18.3.1::gentoo USE="classic dri3 egl gallium gbm llvm -abiwrapper -d3d9 -debug -gles1 -gles2 -lm_sensors -opencl -osmesa -pax_kernel -pic (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -wayland -xa -xvmc" ABI_X86="(-32) (-64) (-x32)" MULTILIB_ABI="amd64 x86" VIDEO_CARDS="(-freedreno) -i915 -i965 (-imx) -intel -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" 0 KiB Some mesa updates introduced these problems we're seeing in your build.log, rumor said that mesa update dropped support for opengl3 with older cards. egl+gles still worked with them. However looks like you're not running old hardware, and your GL support doesn't come from mesa either. I'm really worried if the ebuild needs to do some dirty tricks to support opengl with nvidia. Could you test renaming your /usr/include/GL/gl.h and manually symlinking the nvidia's installed one there, then enable USE="opengl"? I don't have an nvidia card, but I'll setup a chroot environment if that doesn't give any answers. Sorry, I think nvidia ships it whole own include/GL/ directory that you could symlink, or edit INCLUDEDIR to ignore /usr/include/GL and search from nvidia's path. I dont see any header files in the installed list for nvidia-drivers. Which files from which package should i try instead of the mesa ones? Oh right, I might've mistaken GL.h with libGL.so, that the nvidia one provides. I'm setting up a new amd64 chroot and gonna try with your ENV settings, but need to emerge 400 packages first... Will get back at this. Well, *whew*, it compiles with nvidia-drivers. I.. kinda dare to say the problem lies with mesa rather than with efl somewhere, probably in the target environment. Is the target's mesa up-to-date etc correct ABIs? (Does full opengl actually work in it?) I'm gonna try to crosscompile amd64 -> x86 next, but will have to do that later next week. I see the same on hppa with mesa-18.3.2. (In reply to Rolf Eike Beer from comment #9) > I see the same on hppa with mesa-18.3.2. Crosscompile, or native host? Are you using nvidia, or something mesa-supported? (Sorry no idea about hppa hw) Does it work with 'gles2 -opengl' USE? I also had this issue (not crosscompiling but compiling natively), and turns out it was fixed upstream. Upgrading to latest efl-1.22.2 fixes it. https://git.enlightenment.org/core/efl.git/commit/src/lib/evas/Evas_GL.h?id=0d2b624f1e24240a1c4e651aa1cfe9a8dd10a573 https://phab.enlightenment.org/T7502 |
