Bug 57702 - Eliminate RTLD_GLOBAL glapi hacks after removing support for static libglapi
Summary: Eliminate RTLD_GLOBAL glapi hacks after removing support for static libglapi
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-29 21:30 UTC by Alexander Monakov
Modified: 2014-10-29 23:11 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Monakov 2012-11-29 21:30:32 UTC
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.
Comment 1 Emil Velikov 2014-09-22 18:08:45 UTC
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.
Comment 2 Emil Velikov 2014-09-22 19:55:10 UTC
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"
Comment 3 fjhenigman 2014-10-29 23:11:50 UTC
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:

chrome:
http://src.chromium.org/chrome/trunk/src/ui/ozone/platform/dri/ozone_platform_gbm.cc

wayland:
http://fossies.org/linux/weston/src/compositor-drm.c

enlightenment:
https://git.enlightenment.org/core/efl.git/commit/?h=devs/devilhorns/drm&id=73a7ac2ec8201123785ec17eff97364f72a474a1

Now I find waffle has the same problem.  Do I need to add the same hack there?
https://github.com/waffle-gl/waffle/pull/21

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?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.