This is an enhancement request for the time when support for static libglapi is removed. When shared libglapi is guaranteed to be available, please:
1. Link DRI drivers with libglapi.so explicitely.
2. Remove dlopen("libglapi.so"/"libGL.so", RTLD_GLOBAL) hacks in src/egl/drivers/dri2/egl_dri2.c and src/glx/dri_common.c. The latter hack has unfortunate interactions with libGL interposers.
I'm do not thing the lack of explicit link is our biggest issue. Afaick we aim to preserve compatibility different versions of mesa and the xserver.
Up-to recently the server the second provider for those _glapi* symbols, thus the lack of explicit link, and the need to dlopen.
Perhaps we can have a discussion at XDC at when we can say "enough is enough" and resolve these.
Pardon for the non-comprehensive reply there. The funny sentences should read
"I do not think that the lack of explicit link is our biggest issue"
"Up-to recently the xserver was the second provider for those _glapi* symbols"
If I'm understanding correctly:
- this bug asks that, for example, /usr/lib64/dri/i965_dri.so pull in libglapi
- at the moment it's deliberately not pulled because some use case didn't want that
- that other use case no longer exists in current code, but there's reluctance to break older versions by making the requested change
- in time, fear of breaking old code will reduce, and this change could happen
Here's another reason for making that change: gbm_create_device() fails because dlopening (for example) i965_dri.so fails due to missing glapi symbols. Unless you link in or dlopen libglapi, or link in something that pulls it in such as libGL. The dlopen(libglapi) hack seems to be widespread:
Now I find waffle has the same problem. Do I need to add the same hack there?
If we must use the hack for now, wouldn't it be better in gbm_create_device, so every
gbm user doesn't clutter their code with it?