Summary: | dev-libs/DirectFB-1.7.1[egl]: egl_system.c:75:6: error: unknown type name ‘EGL_DISPMANX_WINDOW_T’ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | [OLD] Games | Assignee: | Gentoo Graphics Project <graphics+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bertrand, cbatdotcom, jmesmon, pageexec, polidevk.polidevk |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Juergen Rose
2014-01-05 09:37:08 UTC
There's something interesting a bit earlier: checking for MESA... no configure: WARNING: *** gl egl libdrm gbm packages not found -- Building without MESA support. So, what does config.log say about this ? What does pkg-config say about these packages ? systems/egl/egl_system.c seems to define RASPBERRY_PI unconditionally which in turn enables code that refers to EGL_DISPMANX_WINDOW_T and results in compile failure presumably for any target that's not an rpi (at least that typedef is nowhere to be found here). commenting out the #define is not enough as at around line 151 there's a reference to nativewindow outside of the rpi ifdef. fixing that will then result in compile errors elsewhere for me: idirectfbvideoprovider_xine_vdpau.c:64:34: fatal error: xine/video_out_vdpau.h: No such file or directory so it looks like this release is bleeding from several wounds... according to the homepage, 1.8.0 will be out "shortly" maybe report this upstream? Why is this package not getting masked? If it doesn't emerge, why is it there? (In reply to Billy DeVincentis from comment #4) > Why is this package not getting masked? If it doesn't emerge, why is it > there? we don't hardmask packages, just because there is a bug in ~arch (which means unstable branch) It emerges perfectly fine with egl useflag disabled. If you have a fix, please share it. (In reply to Julian Ospald (hasufell) from comment #5) > (In reply to Billy DeVincentis from comment #4) > > Why is this package not getting masked? If it doesn't emerge, why is it > > there? > > we don't hardmask packages, just because there is a bug in ~arch (which > means unstable branch) > > It emerges perfectly fine with egl useflag disabled. If you have a fix, > please share it. Only set USE=-egl does not help, 'USE=-egl emerge -uvDN DirectFB' fails with: root@leopard:/home/rose/Txt/Configurations/usr/src/linux(45)# USE=-egl emerge -uvDN DirectFB These are the packages that would be merged, in order: Calculating dependencies... done! !!! The ebuild selected to satisfy "media-libs/mesa[gbm,egl?,gles2?]" has unmet requirements. - media-libs/mesa-9.2.5::gentoo USE="classic gallium gbm llvm llvm-shared-libs nptl openvg vdpau xa xvmc -bindist -debug -egl -gles1 -gles2 -opencl -osmesa -pax_kernel -pic -r600-llvm-compiler (-selinux) -wayland -xorg" ABI_X86="64 -32 -x32" VIDEO_CARDS="nouveau -freedreno -i915 -i965 -ilo -intel -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware" The following REQUIRED_USE flag constraints are unsatisfied: openvg? ( egl ) The above constraints are a subset of the following complete expression: llvm? ( gallium ) openvg? ( egl gallium ) opencl? ( gallium llvm-shared-libs video_cards_r600? ( r600-llvm-compiler ) video_cards_radeon? ( r600-llvm-compiler ) video_cards_radeonsi? ( r600-llvm-compiler ) ) gles1? ( egl ) gles2? ( egl ) r600-llvm-compiler? ( gallium llvm any-of ( video_cards_r600 video_cards_radeonsi video_cards_radeon ) ) wayland? ( egl ) xa? ( gallium ) xorg? ( gallium ) video_cards_freedreno? ( gallium ) video_cards_intel? ( any-of ( classic gallium ) ) video_cards_i915? ( any-of ( classic gallium ) ) video_cards_i965? ( classic ) video_cards_ilo? ( gallium ) video_cards_nouveau? ( any-of ( classic gallium ) ) video_cards_radeon? ( any-of ( classic gallium ) ) video_cards_r100? ( classic ) video_cards_r200? ( classic ) video_cards_r300? ( gallium ) video_cards_r600? ( gallium ) video_cards_radeonsi? ( gallium llvm ) video_cards_vmware? ( gallium ) And 'USE="-openvg -egl" emerge -uvN DirectFB' fails either: ... libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../lib -I../../lib/fusionsound -I../../include -I../../lib -I../../lib/fusionsound -I../../src -I../../systems -DDATADIR=\"/usr/share/directfb-1.7.1\" -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DHAVE_GSTREAMER_1_0_API -DDATADIR=\"/usr/share/directfb-1.7.1\" -I../../lib/dvc -D_REENTRANT -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-strict-aliasing -ffast-math -march=native -O2 -pipe -D_GNU_SOURCE -std=gnu99 -c idirectfbvideoprovider_gif.c -fPIC -DPIC -o .libs/idirectfbvideoprovider_gif.o idirectfbvideoprovider_xine.c:170:1: warning: no previous prototype for 'BufferThread' [-Wmissing-prototypes] BufferThread( DirectThread *self, void *arg ) ^ idirectfbvideoprovider_xine.c: In function 'event_listener': idirectfbvideoprovider_xine.c:1468:21: warning: 'xine_mrl_reference_data_t' is deprecated (declared at /usr/include/xine.h:1983) [-Wdeprecated-declarations] xine_mrl_reference_data_t *ref = event->data; ^ idirectfbvideoprovider_xine.c: In function 'BufferThread': idirectfbvideoprovider_xine.c:191:21: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result] write( fd, buf, len ); ^ idirectfbvideoprovider_xine_vdpau.c:64:34: fatal error: xine/video_out_vdpau.h: No such file or directory #include <xine/video_out_vdpau.h> ^ compilation terminated. Makefile:1031: recipe for target 'idirectfbvideoprovider_xine_vdpau.lo' failed make[4]: *** [idirectfbvideoprovider_xine_vdpau.lo] Error 1 Is there not any workaround, which enables the installation of DirectFB-1.7.1 on ~amd64 systems? see bug 499740 (In reply to Julian Ospald (hasufell) from comment #7) > see bug 499740 'USE="-xine -egl" emerge -v1 DirectFB' worked. no fix since 4 months, no idea how to report bugs upstream + 05 Apr 2014; Julian Ospald <hasufell@gentoo.org> package.mask: + mask >=dev-libs/DirectFB-1.7.1 wrt #499740 and #497124 looks like the egl logic is specific to the Raspberry Pi rather than sticking to the standard OpenGLES API should be all set now in the tree; thanks for the report! Commit message: Do not hard define raspberry pi support for egl targets http://sources.gentoo.org/dev-libs/DirectFB/DirectFB-1.7.1.ebuild?r1=1.3&r2=1.4 |