Regis Boudin <regis@boudin.name> (2016-01-11): > Indeed it is inverted. And with the screenshot feature not getting > built for deb, I managed to miss it. Combined with the fact I've had > to disable -Werror because of some gcc warning flags. > I'll try to see if I can fix the warnings, unfortunately we use > asprintf quite a lot. > > > The black screen seems easily explained by some missing symbols, > > leading to a UI crash (nothing shows up when grepping for gtk in > > /proc/*/maps). > > Actually, what happens is that dlopen() fails to load the plugin > because all symbols cannot be resolved (been there with my tests). But > that's more informative. > > > Inverting the logic fixes the black screen with gtk2, so I'm about > > to commit it. > > Thanks, that was definitely the right thing to do, as it would > otherwise break gtk2 as well. Great, thanks for confirming. > > Going back to a gtk3 build, I'm again getting a black screen, > > because something is trying to open libGL.so.1; the only hit in the > > temporary build tree is libepoxy (unsurprisingly, since that's an > > OpenGL wrapper). > > Oh dear. that sounds... big. But unsurprising, with dlopen failing, > just like in the previous case. This is slightly different: I had checked libepoxy0's (and therefore libepoxy0-udeb's) dependencies, both as Debian packages and as ELF binaries, and those are satisfied. libepoxy implements finding libGL internally (through do_dlsym on GLX_LIB, see src/dispatch_common.c, which ends up in turn with dlsym()). > > I'll be poking the libgtk-3-0-udeb bug report to see if we could > > do without pulling libepoxy/libGL… > > Well, that's at least one thing this patch will have been useful to > find out and try to track. > > Thanks a lot for the prompt testing and bug fixing. Bah, you did all the heavy work. I'm only pointing out what isn't working yet. ;) Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature