gallium/dri: always link against shared glapi
authorEmil Velikov <emil.velikov@collabora.com>
Thu, 13 Apr 2017 17:54:03 +0000 (18:54 +0100)
committerEmil Velikov <emil.l.velikov@gmail.com>
Thu, 4 May 2017 17:11:29 +0000 (18:11 +0100)
commit79a26b663acdffc3f21d6e37f3334495aed16ae5
treeeca1096ab08898a3eb0d915cf49b075534fe7dd8
parent9d2aa6e5067752efbc0acbd728bc0bde49aefb61
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: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98428
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
src/gallium/targets/dri/Makefile.am