gbm: work around mesa linkage issue

[fjhenigman]

Mesa drivers such as i965_dri.so use symbols from libglapi but do not
pull in libglapi (https://bugs.freedesktop.org/show_bug.cgi?id=57702)
so dlopen libglapi before we need it.

[evelikov]

Afaik one does not use gbm directly but via libEGL(at least in the context of waffle), and the latter already ldopens libglapi.so.0. Thus this should not be needed. Additionally I've send some patches that link the dri modules against libglapi, but I'm yet to get any input on them.

[evelikov]

I stand corrected. The semantics of gbm and EGL dictates that gbm is to be used first, which requires that the symbols in the dri modules must be resolved by/around the former. Perhaps we ought to fix the dri modules once and for all, with all projects using gbm bumping their requirement to mesa 10.4 (due in a couple of months) ?

[versalinyaa]

@fjhenigman I see a problem with you fix, unless I don't understand things correctly. Won't this break Waffle on systems that don't have Mesa? I'm specifically thinking about Mali with minigbm.

Even if this fix doesn't break non-Mesa GBM, I still think this solution violates Mesa's ABI contract. libglapi is a Mesa-private library, even if vendors don't package it as such. I think it's wrong to dlopen a private library that belongs to a separate project.

As you state in [https://bugs.freedesktop.org/show_bug.cgi?id=57702], I think the proper fix belongs in GBM itself. I'll talk to Kristian about that on Monday.

I see that Chromium and Weston also implement this hack. But, have you encountered any real problems using Waffle without this hack? I'm curious, because this problem has not affected me yet in my Waffle usage.

[fjhenigman]

@evelikov is trying to get this fixed in mesa: http://patchwork.freedesktop.org/patch/36392/

I did have a real problem: wflinfo would not run with the gbm backend.

dlopen(libglapi) can silently fail with no harm, so the hack shouldn't cause problems?
But hopefully a mesa fix lands and we can forget the hack.

[evelikov]

@chadversary now that I've dropped the libGL dependency in waffle (patches are coming shortly), the issue is quite prominent.
Originally: libGL and libEGL explicitly link against libglapi (with the libEGL case being an over-link). As such as soon as libgbm opens the dri module, the symbols are already resolved.
Currently: (origin/master, with the drop egl link patches), if one builds waffle without glx, the last remaining link to glapi is lost and waffle falls on the ground.

My take on the whole issue is this:

• Ideally the dri modules will be linked against glapi, but mesa's dispatch is a bit broken for that.
• Workaround: call dlopen(libglapi) from libgbm, similar to libGL and libEGL.
• If third party (closed source) provides dri modules, that are not compliant with the ones from mesa yet use mesa's libgbm the workaround may cause issues, but that is their own fault.
• libglapi is private, and as such we should encourage users [1] to drop the hacks, and use fixed mesa.

@fjhenigman do you have an example when dlopen(libglapi) from libgbm will fail, and things will work considering that the hacks in the users [1] are nuked ?

[1] Chromium, Weston, any other program that uses libgbm.

[fjhenigman]

@evelikov To answer your question, if dlopen(libglapi) fails (whether it's done inside mesa or in user code) then the program fails unless it's linked with libGL or something that pulls in libglapi. But you know that so ... sorry, I don't understand what you actually wanted to know. Can you elaborate the question?

[versalinyaa]

@fjhenigman After this discussion, I'm now ok with merging your fix.

As you pointed out, the workaround causes no harm.

dlopen(libglapi) can silently fail with no harm, so the hack shouldn't cause problems?

I'll merge it in the morning. (It's late for me, and I avoid committing code when I'm sleepy. Too easy to make mistakes).