On Sat, Nov 10, 2012 at 02:30:03AM +0100, gregor herrmann wrote: > On Fri, 09 Nov 2012 09:51:05 +1030, Ron wrote: > > > > My impression at the moment is: > > > - There's a bug but mumble still works, as confirmed by the submitter > > And the fix should be trivial. libmumble uses symbols from libGL but > > doesn't link to it, and so will fail unless that's fixed and it does. > > So, let's fix it :)
Thanks! \o/ > The term "trivial" triggered me into trying it myself. I'd hoped so :) I've got a small mountain of backlog still to dig through right now, and this still isn't anywhere near the top of it just yet, so that's much appreciated! > The attached patch adds -lGL to LIBS in overlay_gl/overlay_gl.pro > which seems to determine the libmumble build. Indeed. Minor nit, I'd probably put -lGL at the front of that list, but mostly that's an old habit from when order mattered with one-pass static lib linking - it's less of a deal if this is shared libs only. so LIBS *= -lGL -lrt -ldl instead of LIBS *= -lrt -ldl -lGL > The result: > > - No more "undefined symbol" errors when starting mumble: That part is completely expected. > - libmumble is linked against libGL (and many more things (?)): That's fine, that's just ldd resolving the full chain of all things that libs libmumble depends on depend on too. ldd on /usr/lib/x86_64-linux-gnu/libGL.so.1 will show you the rest of those, and that list might change if libGL ever changes its deps (and we'd need to do nothing extra here if it ever did, not even recompile, ldd would just show a different list of those). > > > of the LP bug and by Chris now. So the priority is probably fine. > > That kind of depends on whether it's considered acceptable for the > > mumble-overlay / preloading libmumble described in the README to be > > completely broken for Wheezy. Since that clearly can't work as it is > > documented if libmumble can't be loaded because of a broken DT_NEEDED. > > Ok, so the problem is not starting mumble itself, as reported by dkg, but > mumble-overlay / preloading libmumble ... Yeah, he spotted one symptom, but that's not really the primary problem that he actually brought to light here. So I guess the two interesting questions remaining now are: - Does it actually work! - and when do we want to upload it if it does ... The first I'm a bit less certain about now, since libmumble actually tries to be a bit trickier than your average preload library ... It's both overriding symbols from libGL *and* using them via normal linkage. Linking to libGL is certainly the correct solution for the latter, which was the symptom the original report made apparent, but that may have now gone and broken the overriding that the preload would normally do, since we've now forced libGL to be loaded before the libmumble symbols are resolved ... (I had a quick dig through this myself, since I figured if I was asserting it was trivial, it would probably pay to be sure of that, and this tossed an extra layer of uncertaintly into the mix) It does some tricky fun with overriding dlsym, to intercept requests for the symbols it wants to override and that might still catch them, but without running some actual tests I'm not 100% certain of that, and that's where I ran out of time for this and had to drop it again. You should be able to do the preload trick from the README with any app that calls glXSwapBuffers(), and if you also set MUMBLE_OVERLAY_DEBUG=1 in your environment, it should bark a bunch of debug messages at you when it is doing things. If that works, we're looking good. If not, it might be back to the drawing board for a slightly different solution ... If it does work, I guess the question is whether we push this now, or let the release team get through reviewing the current candidate and then push the one liner after that migrates. The latter might be better, but I guess we should let them make that call :) Thanks Gregor! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
