Commit 5c9a9ba9 authored by Emil Velikov's avatar Emil Velikov Committed by Andres Gomez

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 provides the
GLAPI) and new Mesa (with DRI modules linking against

That should still work, since the the symbols will take
precedence over the 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.

Bugzilla: default avatarEmil Velikov <>
Reviewed-by: default avatarNicolai Hähnle <>
(cherry picked from commit 79a26b66)
parent f2d6c630
include $(top_srcdir)/src/gallium/
SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/
-I$(top_srcdir)/src/mapi \
......@@ -31,8 +29,10 @@ gallium_dri_la_LDFLAGS = \
-shared \
-shrext .so \
-module \
-no-undefined \
-avoid-version \
gallium_dri_la_LDFLAGS += \
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment