summaryrefslogtreecommitdiffstats
path: root/src/gallium/targets/vdpau/vdpau.sym
diff options
context:
space:
mode:
authorEmil Velikov <[email protected]>2017-04-13 18:54:03 +0100
committerEmil Velikov <[email protected]>2017-05-04 18:11:29 +0100
commit79a26b663acdffc3f21d6e37f3334495aed16ae5 (patch)
treeeca1096ab08898a3eb0d915cf49b075534fe7dd8 /src/gallium/targets/vdpau/vdpau.sym
parent9d2aa6e5067752efbc0acbd728bc0bde49aefb61 (diff)
gallium/dri: always link against shared glapi
In the early days of Xorg and Mesa we had multiple providers of the GLAPI. All of those were the ones responsible for dlopening the DRI module. Hence it was perfectly fine, and actually expected, for the DRI modules to have unresolved symbols. Since then we've moved the API to a separate shared library and no other libraries provide the symbols. Here comes the picky part: It's possible that one uses old Xorg (where libglx.so provides the GLAPI) and new Mesa (with DRI modules linking against libglapi.so). That should still work, since the the libglx.so symbols will take precedence over the libglapi.so ones. I've verified this while running 1.14 series Xorg alongside this (and next) patch. It may seem a bit fragile, but that's of reasonably OK since all of the affected Xorg versions have been EOL for years. The final one being the 1.14 series, which saw its final bug fix release 1.14.7 in June 2014. To ensure that the binaries do not have unresolved symbols add -no-undefined and $(LD_NO_UNDEFINED), just like we do everywhere else throughout mesa. Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98428 Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
Diffstat (limited to 'src/gallium/targets/vdpau/vdpau.sym')
0 files changed, 0 insertions, 0 deletions