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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Oct 28 19:05:07 UTC 2016


--- Comment #6 from ajax at nwnk dot net <ajax at nwnk.net> ---
(In reply to Emil Velikov from comment #5)

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

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/20161028/2fdc1163/attachment-0001.html>

More information about the mesa-dev mailing list