[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 #4 from ajax at nwnk dot net <ajax at nwnk.net> ---
(In reply to Emil Velikov from comment #3)
> 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.

Shot down? How?

> 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.

"The" entry points. Which, glapi? If so, no, the DRI drivers really should be
linking against it.

> 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 you're using shared glapi - and you really should be - then no. Both libGL
and the DRI driver would be linked against libglapi and that's just fine, same
way everything in the world is linked against libc and there's no collision.

>  - 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).

We're likely to want libGLdispatch to be stable API anyway, yes. Consider this
bit of discussion:

https://github.com/NVIDIA/libglvnd/pull/100#issuecomment-254588402

-- 
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/7cebf232/attachment.html>