Hi Franks, On 9 November 2014 at 15:17, Frank Henigman <fjhenig...@google.com> wrote: > On Sat, Nov 8, 2014 at 7:13 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 06/11/14 21:29, Frank Henigman wrote: >>> From: Frank Henigman <fjhenig...@chromium.org> >>> >>> Dri driver libs are not linked to pull in libglapi so gbm_create_device() >>> fails when it tries to dlopen them (unless the application is linked >>> with something that does pull in libglapi, like libGL). >>> Until dri drivers can be fixed properly, dlopen libglapi before trying >>> to dlopen them. >>> https://bugs.freedesktop.org/show_bug.cgi?id=57702 >>> >> Hi Frank, >> >> I think I can understand the frustration that this has caused you, so >> unless there are any objections I will gladly pick it up for the 10.4 >> (and if there are no side effects for the stable 10.3 branch). >> >> Just a couple of nits, which I'm planning to make prior to pushing this >> (a week from now, just before the branchpoint) >> * the bugzilla report mentiones libglapi, but in a different light so >> I'll rephase the commit msg a bit. >> * we might as well print out an error message and bail out when we >> dlopen fails. > > I think the check should be after the dlopen() of blah_dri.so, a few lines > down, > and show the dlerror() message if that fails. That's the code I've > put in in the > past to diagnose this issue, and I really should have included it in my patch. > Then there's probably no need to error check the new dlopen, and the later > check can stay in when the new dlopen is removed. > Thanks! > Apologies for dropping the ball on this one - I managed to get it mangled somehow.
There shouldn't be (m)any problems with pre-emptively dlopen-ing the library, and I'll resent this (plus a small note that the libname differs across platforms) as part of a larger series. Cheers, Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev