opencv 3.1.0 ebuilds have a USE=gtk and USE=opengl, former of which pulls in gtk+:2 and also gtkglext if the latter (USE=opengl) is set. But then passes explicitly WITH_GTK_2_X=OFF to the build system. So the actual result from the build is quite different: -- GUI: -- QT: NO -- GTK+ 3.x: YES (ver 3.22.4) -- GThread : YES (ver 2.50.2) -- GtkGlExt: NO -- OpenGL support: NO -- VTK support: NO That's because WITH_GTK does gtk3 and gtkglext is not ported to gtk3, so it won't support OpenGL and so is disabled. I'm happy it has gtk3 support and would prefer that be kept as the chosen gtk version if at all possible, but the dependencies and such are all wrong for gtk stuff right now. This logic is coded in cmake/OpenCVFindLibsGUI.cmake I don't see any improvements in this matter (in terms of the gtk3 version getting OpenGL support) in the opencv-3.2 source either. For gtk3, there is actually no need for gtkglext for the most part, as the functionality is now part of gtk+ itself: https://developer.gnome.org/gtk3/stable/GtkGLArea.html But unfortunately they don't use that yet to provide gtk3 opengl support. Please fix the depends to reality, whichever way you go: * gtk3 without opengl, in which case need to use the correct slots for gtk+ and glib and not have a opengl block; or * gtk2 with optional opengl, in which case need to pass -DWITH_GTK=OFF and -DWITH_GTK_2_X=$(usex gtk) I of course (with my gnome team hat on) would prefer the former if the opengl part isn't that important.
Sorry, I was wrong in terms of -DWITH_GTK=OFF. If you choose to go with gtk, actually both WITH_GTK and WITH_GTK_2_X would have to be $(usex gtk) as WITH_GTK is used as "use gtk+ at all" and then if that is set, WITH_GTK_2_X is checked to use gtk2 instead of gtk3.
(In reply to Mart Raudsepp from comment #1) > Sorry, I was wrong in terms of -DWITH_GTK=OFF. If you choose to go with gtk, > actually both WITH_GTK and WITH_GTK_2_X would have to be $(usex gtk) as > WITH_GTK is used as "use gtk+ at all" and then if that is set, WITH_GTK_2_X > is checked to use gtk2 instead of gtk3. So if I understand the problem correctly. If we change this -DWITH_GTK=$(usex gtk) -DWITH_GTK_2_X=OFF to -DWITH_GTK=$(usex gtk) -DWITH_GTK_2_X=$(usex gtk) It solves the bug?
If you decide you have to stick with gtk+:2 only, then yes, that should fix it. Are all the consumers having a USE depend properly, so I can find all the consumers that need this and help investigate the gtk2 vs gtk3 thing at some point later? I'll have to circle back later to see about getting rid of gtkglext and then gtk+:2, but that's a 12 months timeline for gtkglext I suppose :D But decision to stick with gtk2 is OK for now. btw, I don't think gtkglext actually does much, might just initialize it as needed to be used by consumers, and with gtk3 having its own GtkGlArea, there is no extra initialization necessary and the consumers that are gtk3 could just use it directly instead. But not if opencv package pulls in gtk2 for them. Anyhow, I think that change is fine for now to fix the deps, and we can circle back on any gtk3 business later on.
commit 24f777d08cddf2fe05031d1c8c63232d6e025724 Author: Amy Liffey <amynka@gentoo.org> Date: Fri Jan 20 15:35:05 2017 +0100 media-libs/opencv: fix gtk bug #605740
