request a new release

[chenrui333]

👋 it has been more than three years since last release, would be good to cut a new release to refresh the downstream packages.

relates to Homebrew/homebrew-core#177962

[nigels-com]

Yes, well overdue.

[markshep-wbg]

I'd second this! I'm getting Unkown error for glewInit() using the official Debian package, but reading the latest source code I should be getting No GLX display due to ea20766 which was committed well over three years ago.

[ManDay]

Question, 2.2.0 tries to link against -lGL and therefore fails on modern X11 free systems. #340 mentions that, too, but I'm not very clear what's the situation there; is the user supposed to modify the Makefile themself?

Will a new release link against -lOpenGL (thus libglvnd)? If so, I think this would be a good reason to push for a release.

[nigels-com]

@ManDay it's a fair question what to do about -lOpenGL.
In the past there was not so much of a need to do a configuration step, but I agree that things have moved on.

[ManDay]

Thanks @nigels-com ! Would it be possible to generally assume libglvnd and link against -lOpenGL without configuration? Systems without libglvnd would be inherently outdated, is my naive understanding.

I suppose the alternative (within the current build system) is adding distinguished targets of the linux-egl-glvnd sorts?

[nigels-com]

So for example we could happily add a config/Makefile.linux-glvnd for that.
The question is more around what should be the default and what should be the opt-in.
GLEW has not done "detection" other than via config.guess, which does not seem sufficient to me.

On the other hand the cmake paradigm is generally a fine-grained auto detection one.
So in this day in age it's a bit of an argument to switch over to cmake and leave the historical makefiles in the past?
I think I'd be supportive of that providing there were options for backward compatibility reasons.

[ManDay]

Is GLEW interested in the window system bindings EGL/GLX? If it really only ever links against OpenGL, then I think switching over to cmake would be effort without a lot in return. FindOpenGL.cmake isn't the cleanest module, in my opinion and also has some problems.

If the question is only -lGL or -lOpenGL I think the most practical fix for now would be just default to -lOpenGL.

[nigels-com]

@ManDay Just to clarify, we're talking about config/Makefile.linux specifically? Want to take a stab at that?

[ManDay]

Ok, it links against -lGLX and I can see GLX syms in the code; I didn't think of it like that. I thought GLEW only concerned OpenGL itself, but not GLX. So I guess cmake would be the right choice, then. With all the stuff going on in Makefile, porting it to cmake is going to be a major endeavour for me, though, if that's what you mean by taking a stab at it.

Alternatively, modify the Makefile.*egl* targets to just use -lOpenGL instead of -lGL?

[nigels-com]

Yes, if that's more appropriate for EGL, than GLX, I'm supportive of that in particular.
It's the binary compatibility for old GLX and WGL binaries that I'm more conscious of.

[ManDay]

I don't think the ABI is affected here. The symbols are still the same and just in different libraries. That said, -lGL should probably be replaced by -lOpenGL everywhere, not just in the EGL target?

[nigels-com]

The ABI is the exported symbols, but also the shared library dependencies?

make SYSTEM=linux

$ ldd lib/libGLEW.so.2.2
	linux-vdso.so.1 (0x00007fff38bda000)
	libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x000079d237ce9000)
	libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x000079d237c31000)
	libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x000079d237bfe000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000079d237800000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x000079d237ac1000)
	/lib64/ld-linux-x86-64.so.2 (0x000079d237e63000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x000079d237a96000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x000079d237a90000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x000079d237a88000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x000079d237a72000)
	libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x000079d237a63000)

[ManDay]

Please forgive my ignorance (I'm notoriously a bit daft when it comes to maintaining compatibility), but where is the actual problem if a newer release of GLEW depends on other shared libraries than an older release? Isn't that a very natural thing to happen during releases of newer versions?

[nigels-com]

GLEW has been binary-compatible for at least a decade. (Maybe two?)
As a maintainer I'm reluctant to have changes that result in disruption, questions and complaints.
I'm fine with opt-in for new stuff, and I'm aware that distros like Debian, Ubuntu and Fedora can customise the settings.
If cmake is the vehicle for contemporary configuration and GNU make is stability-oriented, seems like that could be the best of both worlds?
I could write that up as a documented intention, if it makes broad sense.

[nigels-com]

Or to put it another way, you're already free (encouraged even) to tweak the build flags or propose a new SYSTEM variant via a PR.
But when it comes to what should happen for everyone else, it's a bit less clear (to me) if the (potential) gain is worth the (potential) pain.
One difficulty for me is that I have not actively used GLEW for a decade or so. (So I lean to the cautious side)

[ManDay]

I fail to understand what concrete problem a change of dependencies would create or how this affects binary compatibility (i.e. being able to depend on a newer version of GLEW without having to recompile). Anyone who insists on the -lGL dependency for whatever reason is free to not upgrade, or am I missing something?

It's not just any change, either, but something which is, or will be, required of modern systems by upstream OpenGL/Khronos. Sooner or later, no reasonable system will still have libGL. Are we looking at the ratio of downstream consumers who have libGL (deprecated) versus libOpenGL (modern). And if it's 50/50, are we still choosing to be "incompatible" (to the extent given in this case) with modern systems, at the favor of deprecated ones?

If we change to cmake, that would also imply a change of dependencies (cmake becomes a new dep), so wouldn't it be just as "problematic"?

I suppose at this point it's just my lack of appreciation for a maintainer's perspective. I can understand that you have a more wholly concept of the situation.

[nigels-com]

To a large extent GLEW is in maintenance mode - the main priority is to support the existing ecosystem.
But if the old assumptions are broken on modern systems (due to EGL, Wayland, or whatnot) I'm open to a discussion.
On Linux for example, how to support X11/GLX if we're seeing a splintering which has a good portion of systems without X11 and GLX?
Should X11/GLX still be the default for Linux?
I still run Nvidia/GLX/X11 because Wayland "doesn't seem ready", but that's just my opinion/preference/reality.

[ManDay]

I suppose the reasonable way forward is then to just assume packagers will configure it directly with LDFLAGS or, at most, expose a dedicated make variable to just switch between the two. Porting it all to cmake just for this tiny "automated detection" feels like a major overkill to me. In any event, I retract my statement that this would be a good reason for a new release 🙂 . Thank you for discussing it!!

[nigels-com]

All good. Since I don't use GLEW all that much myself, very interested in what's going on "out there" in GLEW land.

[dg0yt]

Out there in "vcpkg land", I really wonder how much the vcpkg port (GLEW 2.2.0 + 4 patches) differs from the master branch (GLEW 2.2.0 + 59 commits). GLEW 2.2.0 is 4 years old, and it is hard to imagine that there are no commits would which would justify a patch releases. Release also encorage upstreaming of modifications.