[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: More cdebconf patches

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. ;)


Attachment: signature.asc
Description: Digital signature

Reply to: