[Mesa-dev] [PATCH] gbm: dlopen libglapi so gbm_create_device works
emil.l.velikov at gmail.com
Fri Jun 19 11:55:11 PDT 2015
On 9 November 2014 at 15:17, Frank Henigman <fjhenigman at google.com> wrote:
> On Sat, Nov 8, 2014 at 7:13 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 06/11/14 21:29, Frank Henigman wrote:
>>> From: Frank Henigman <fjhenigman at 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.
>> 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.
Apologies for dropping the ball on this one - I managed to get it
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.
More information about the mesa-dev