[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 #5 from Emil Velikov <emil.l.velikov at gmail.com> ---
(In reply to ajax at nwnk dot net from comment #4)
> (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.
> 
Yes, the glapi entry points.

Are old xservers (ones which includes their own glapi dispatch) + glapi linked
dri modules going to work ?

I thought the answer was no ? In that case we might want to check again with
Ian, if the (his?) idea of keeping the DRI loader/driver is still feasible.

And if we go for breaking things, there's a _ton_ of things we can drop and/or
fix ;-)

> > 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.
> 
I do agree that we want to link against glapi, although one needs to convince
distros and(?) Ian that breaking old libGL (admittedly only static ones) is
fine.

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

I've mentioned a similar thing [1] [2] and it seems that one "has to" go
through the winsys library/ies [2].

Even convincing to version GLdispatch.so ended up quite a process [3].

My personal favourite: "To clarify: libGLdispatch.so does not have an ABI." 
Sure it doesn't ... ;-)

[1] https://bugs.freedesktop.org/show_bug.cgi?id=92877#c2
[2] https://github.com/NVIDIA/libglvnd/pull/85
[3] https://github.com/NVIDIA/libglvnd/issues/59.

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