[Mesa-dev] [Bug 98428] Undefined non-weak-symbol in dri-drivers

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98428

--- Comment #3 from Emil Velikov <emil.l.velikov at gmail.com> ---
On a more comprehensive note:

One of the goals behind GLVND is to reuse mesa's GLAPI and allow us to drop our
"copy". The latter seems to have diminished and my attempts to get it back on
board have been shot down, sort of speak.

The original issue:

Ajax would be one of the better people to answer this, but the gist is that
there can/could be than one provider* for the entry points - which one gets
picked is (implicitly) determined by the specific DRI loader.

Thus if we link against the "wrong" provider things will end up badly.

At the same time - DRI loader/driver interface is (and was last time I've
tried) stable. So if one is to use a) old libGL.so which provides the symbols
and b) new DRI module (linked against libglapi.so) you get symbol collision.


If we are to break the stability we should consider:

 - DRI drivers which don't receive much love these days, don't support latest
version of __DRI_EXTENSION v19 or are missing the some extensions all together.

 - dri1,2,3 capability/support

 - Support for old server(s) - eg. make libEGL/x11 require DRI2 minor >= 3

 - Dropping {barely ,un}used codepaths - eg. loaders mandate __DRI_DRI2 >= 4
and similar on the driver side.

 - And last but not least - reuse GLVND dispatch. For this we would need to
convince Kyle that GLdisplatch.so can be accessible by vendors and it gets some
ABI stability (note the GLVND libraries in general seem ABI unstable).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161025/cd2e8072/attachment.html>