[Mesa-dev] [PATCH] st/dri: Fix driver loading if swrast isn't built
Emil Velikov
emil.l.velikov at gmail.com
Sun Aug 3 10:30:31 PDT 2014
On 03/08/14 18:13, Aaron Watry wrote:
> On Sun, Aug 3, 2014 at 12:00 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 02/08/14 22:21, Aaron Watry wrote:
>>> If building hardware drivers only, then kms_swrast_create_screen
>>> won't be defined in inline_drm_helper.h and hardware drivers will
>>> fail to dlopen as a result.
>>>
>> Hmm it seems that it will fail to dlopen due to the unresolved symbol
>> 'kms_swrast_create_screen'. I wonder if we can fix the "_glapi*" symbols (link
>> against glapi ?) and add --no-undefined for the dri modules. It will save us a
>> bit of headaches/head-scratching.
>>
>
> Yup, when I finally managed to bisect this down to the commit that
> added the kms_swrast_create_screen function, I went back to the commit
> before that so I could boot X, then applied the kms_swrast commit and
> LIBGL_DEBUG=verbose glxinfo told me that it was missing
> kms_swrast_create_screen when loading radeonsi_dri.so.
>
Ouch, sorry about that.
For a future reference please give new libGL/DRI modules a try (via
LD_LIBRARY_PATH & LIBGL_DRIVERS_PATH) before installing them system-wide.
> It took me a few days of effort here and there to eventually track
> down what failed (debugging issues when you can't launch X at all is a
> bit slower than usual), and if we can make this an error at build/link
> time, that would've been a huge time saver.
>
> Would you mind looking into that? Or should I poke at it when I have time?
>
I've already did and I go stuck as old (pre 1.14 iirc) xserver used to provide
the symbols, which we used due to the gl dispatch in our server-side libglx.so.
Would be great if someone more knowledgeable in the area give us a few tips
and hints on the topic.
Adam are we safe to start linking the dri modules against libglapi ? Any ideas
how that will affect backwards compatibility - i.e. using new mesa + old xserver ?
Thanks,
Emil
> --Aaron
>
>
>> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
>>
More information about the mesa-dev
mailing list