After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 654593 - "dlopening an unversionaed Shared Object is illegal."
"dlopening an unversionaed Shared Object is illegal."
Status: RESOLVED FIXED
Product: cogl
Classification: Platform
Component: GL
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Cogl maintainer(s)
Cogl maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2011-07-14 07:43 UTC by Jasper St. Pierre (not reading bugmail)
Modified: 2011-07-19 14:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Specify the full filename when g_module_open'ing the GL library (5.38 KB, patch)
2011-07-18 17:51 UTC, Neil Roberts
none Details | Review
configure: Add configure options to override the GL library name (2.52 KB, patch)
2011-07-18 17:51 UTC, Neil Roberts
none Details | Review

Description Jasper St. Pierre (not reading bugmail) 2011-07-14 07:43:49 UTC
We try to open "libGL.so", unversioned with gmodule. Apparently that's against the law:

  https://bugzilla.rpmfusion.org/show_bug.cgi?id=1842

(this applies to all of the modules we try to load too, I guess)
Comment 1 Emmanuele Bassi (:ebassi) 2011-07-14 09:14:38 UTC
even though the OpenGL Linux ABI mandates the existence of a libGL.so, as per standard:

  http://www.opengl.org/registry/ABI/

we might just use libGL.so.1 instead of dlopen()'ing libGL.so directly.
Comment 2 Neil Roberts 2011-07-14 09:28:11 UTC
At the moment Cogl is using g_module_path("GL") and it relies on glib to tack on the right prefix and suffix for the library. If we switch to "libGL.so.1" we couldn't use g_module_path so I guess that makes it less portable. Maybe this wouldn't be a big deal though because the current platforms we support where this matters (OSX and WGL) are directly linking to the library instead.
Comment 3 Matthias Clasen 2011-07-14 10:52:08 UTC
dlopening an unversioned object is not 'illegal', thats nonsense
Comment 4 Neil Roberts 2011-07-18 17:51:04 UTC
Created attachment 192206 [details] [review]
Specify the full filename when g_module_open'ing the GL library

Instead of using g_module_build_path with the short name of the GL
library (eg, "GL") and relying on glib to add the suffix and prefix,
the configure script now directly encodes the full name including the
version number (eg, "libGL.so.1"). This is necessary because distros
don't always install the non-versioned suffix for the library.

The GLES libraries are left without the version suffix because it's
not clear what should be placed here and I can't find any
documentation from Khronos to clarify this. Mesa seems to install a
file called libGLESv2.so.2 but the IMG SDK doesn't install any
versioned library. There is an example of dynamically loading
libGLESv2 in the Chromium source code and that does not use the
version suffix even though it does use the version suffix for GL. This
implies that it's at least fairly normal to load the unversioned name
for GLES.
Comment 5 Neil Roberts 2011-07-18 17:51:07 UTC
Created attachment 192207 [details] [review]
configure: Add configure options to override the GL library name

This adds 3 configure options to override the library name that gets
dlopened for GL, GLES and GLESv2. This could be useful for distro
maintainers who have an unusual name for the libraries (for example,
on OpenBSD the GL library appears to be called libGL.so.4). This could
at least be simpler than having to create a distro patch.

The configure options would be used like this:

./configure --with-gl-libname=libGL.so \
            --with-gles1-libname=libGLESv1.so \
            --with-gles2-libname=libGLESv2.so
Comment 6 Neil Roberts 2011-07-19 14:18:44 UTC
Pushed as eb578e4..9b6c1eb