[Mesa-dev] [PATCH 01/13] gallium/dri: always link against shared glapi

[Emil Velikov]

On 30 May 2017 at 22:37, Juan A. Suarez Romero <jasuarez at igalia.com> wrote:
> On Fri, 2017-04-28 at 14:14 +0100, Emil Velikov wrote:
>> From: Emil Velikov <emil.velikov at collabora.com>
>>
>> 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.
>>
>
>
> Turns out that this commit is making install to fail when libdrm is
> installed in /usr/local/lib.
>
>
> To workaround this, exporting LDFLAGS to "-L/usr/local/lib" fixes the
> problem.
>
> But I guess there should be a better way to fix this.
>
There's the one we use in Travis [1], although personally I sort of
consider this ("-L/path/to/bar.so" becomes "-L/path/to/ -lbar" during
install) notourbug.
I might give it another look one of these days, since more and more
people are mentioning it.

-Emil
[1] https://cgit.freedesktop.org/mesa/mesa/tree/.travis.yml#n27