GLEW/GLEWmx so versions do not follow standard convention

[shehzan10]

I discovered this problem as I was porting my application that was buillt with GLEW 1.10 and the new machine had GLEW 1.12. This resulted in an shared library loading error where the application required glew 1.10 but the system had glew 1.12.

I realized that this issue is because there is no symlink between libglew.so -> libglew.so.1.12 (the symlink in between should be libglew.so.1). If the so.1 were present, my application would have only required so.1 and would have then worked with either 1.10 or 1.12 or any other version.

The current symlinks for the SO versions are as below:

~$ ls -l /usr/lib/x86_64-linux-gnu/libGLEW*
/usr/lib/x86_64-linux-gnu/libGLEWmx.so -> libGLEWmx.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10 -> libGLEWmx.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEW.so -> libGLEW.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10 -> libGLEW.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0

The standard way most libraries symlink is libname.so -> libname.so.major libname.so.major -> libname.so.major.minor libname.so.major .minor-> libname.so.major.minor.micro

This means there should be an intermediate libGLEW.so.1 symlink.

I am trying to change this. But given the number of different platforms available in the makefiles, it make take some time getting this done.

[nigels-com]

Thanks for filing this issue and proposing a patch. GLEW has a fairly long history, and I have not been onboard since the very beginning. So it's possible that GLEW needs to be updated for current convenions.

However, I don't think it's intended that a 1.10.0 built application will work with 1.12.0 shared library, and I think it's correct for a Linux distribution to package both versions of the shared library, than assume compatibility.

We like to think of OpenGL as a fixed, stable binary interface. But in practice there are corrections and modifications over time to both the OpenGL specifications (including extensions) and the GLEW interpretation and handling of those. For example, the specific list of functions expected to be non-NULL for a particular extension may change from 1.10.0 to 1.11.0 and again to 1.12.0.

So going down this road seems to imply that the major version number would need to be incremented for each release, whenever there is a break in binary compatibility. Which I think would put you back in the position of needing multiple GLEW libraries on Linux. Which perhaps defeats the purpose of this effort.

I have not made up my mind, I'll go and see what debian and Fedora are doing in terms of library version numbering schemes, and think about what's appropriate for GLEW going forward.

Thanks again for raising this.

[shehzan10]

Thanks for explaining that in detail. What you stated does makes sense from the OpenGL point of view.

I'll wait for you to complete your research.

[nigels-com]

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

What I see on Ubuntu 14.04 seems consistent with the Debian conventions and what is built by the gnu make build.

$ objdump -p /usr/bin/glewinfo | grep NEEDED
NEEDED               libGLEW.so.1.10
NEEDED               libGL.so.1
NEEDED               libX11.so.6
NEEDED               libc.so.6
$ objdump -p /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0 | grep NEEDED
NEEDED               libGL.so.1
NEEDED               libc.so.6

[nigels-com]

$ ls -la /usr/lib/x86_64-linux-gnu/libGLEW*
lrwxrwxrwx 1 root root     19 Apr 13 12:49 /usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10 -> libGLEWmx.so.1.10.0
-rw-r--r-- 1 root root 497728 Jan  2  2014 /usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.10.0
lrwxrwxrwx 1 root root     17 Jan  2  2014 /usr/lib/x86_64-linux-gnu/libGLEW.so -> libGLEW.so.1.10.0
lrwxrwxrwx 1 root root     17 Apr 13 12:49 /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10 -> libGLEW.so.1.10.0
-rw-r--r-- 1 root root 555080 Jan  2  2014 /usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0

[shehzan10]

If you think that the current way is the correct one to move forward, then lets close the PR. I hadn't taken into account that ARB (and other EXT) API will keep getting moved around as new versions come along. I look at this page for version numbering mostly: https://apr.apache.org/versioning.html Assuming that API wouldn't break in newer versions, we could have done the so.1. But assuming its breaking, I think it fine to keep it the way it currently is.

[nigels-com]

I'd like to keep this issue open, if you don't mind too much. There is some work going on to properly support core contexts. Even though there is no intention to break compatibility in a systematic way, I'm wondering if it's time to bump GLEW from version 1 to version 2. In which case it might also be an opportunity to revisit the version numbering scheme. I tend to think of GLEW as being in maintenance mode, and the primary goal is to avoid widespread disruption. But I'd be happy to encourage more discussion.

[shehzan10]

Sounds good. I'll keep a watch for updates.

[nigels-com]

Revisit for GLEW 2.2.0