<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Undefined non-weak-symbol in dri-drivers" href="https://bugs.freedesktop.org/show_bug.cgi?id=98428#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Undefined non-weak-symbol in dri-drivers" href="https://bugs.freedesktop.org/show_bug.cgi?id=98428">bug 98428</a> from <a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> Emil Velikov</a> <pre>(In reply to ajax at nwnk dot net from <a href="show_bug.cgi?id=98428#c4">comment #4</a>) > (In reply to Emil Velikov from <a href="show_bug.cgi?id=98428#c3">comment #3</a>) > > 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: > > <a href="https://github.com/NVIDIA/libglvnd/pull/100#issuecomment-254588402">https://github.com/NVIDIA/libglvnd/pull/100#issuecomment-254588402</a> 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] <a class="bz_bug_link bz_status_NEW " title="NEW - Add support for libglvnd" href="show_bug.cgi?id=92877#c2">https://bugs.freedesktop.org/show_bug.cgi?id=92877#c2</a> [2] <a href="https://github.com/NVIDIA/libglvnd/pull/85">https://github.com/NVIDIA/libglvnd/pull/85</a> [3] <a href="https://github.com/NVIDIA/libglvnd/issues/59">https://github.com/NVIDIA/libglvnd/issues/59</a>.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>