<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#c6">Comment # 6</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:ajax@nwnk.net" title="ajax at nwnk dot net <ajax@nwnk.net>"> ajax at nwnk dot net</a> <pre>(In reply to Emil Velikov from <a href="show_bug.cgi?id=98428#c5">comment #5</a>) > Are old xservers (ones which includes their own glapi dispatch) + glapi > linked dri modules going to work ? Who cares? Anyone still running 1.14 is already in a state of sin. I _suspect_ that 1.14 servers would still work fine in this case, since the copy of glapi in libglx would be ahead of libglapi proper in the resolution search order, so assuming xserver's copy then is compatible with glapi's interface now... If I really need to spin up a Fedora 20 vm to test that theory I suppose I can. > 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. Again, I'm not sure this ends up being a break. If you had an old libGL that linked glapi statically, that copy should win out over the dynamic libglapi from your magically new DRI driver [1], unless I'm seriously misremembering how ELF works. It'd be fragile I admit, since libGL's copy of glapi would need to be compatible with the dynamic one, but that ought to be true. [1] - Seriously though, nobody deploys driver updates like this. If you got a new driver you were already in a position to have updated libGL that you're sure is compatible with the new driver. The interesting compatibility path is that new libGL can load _old_ drivers, in my mind. The other direction seems like it's mostly useful for developers, who are perfectly capable of setting LD_LIBRARY_PATH as well as LIBGL_DRIVERS_PATH while testing.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>