GLEW/GLEWmx so versions do not follow standard convention about glew HOT 8 OPEN

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.

from glew.

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.

from glew.

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

from glew.

$ 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

from glew.

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.

from glew.

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.

from glew.

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

from glew.

Revisit for GLEW 2.2.0

from glew.