glew
glew copied to clipboard
nigels-com
request a new release (and GLX vs EGL on Linux)
👋 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 https://github.com/Homebrew/homebrew-core/pull/177962
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 https://github.com/nigels-com/glew/commit/ea2076658a5bdcc300ac8fde025a296b6a7a7817 which was committed well over three years ago.
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.
@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.
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?
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.
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.
@ManDay Just to clarify, we're talking about config/Makefile.linux specifically? Want to take a stab at that?
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?
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.
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?
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)
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?
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.
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)
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.
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.
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!!
All good. Since I don't use GLEW all that much myself, very interested in what's going on "out there" in GLEW land.
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.
In openSUSE we turn on EGL support in wxWidgets and GLEW. GLEW needed backported patches to correctly build with EGL. It would be nice to get a release as there are still quite some projects out there using it (OpenSCAD, PrusaSlicer, ...)
https://build.opensuse.org/package/show/multimedia:libs/glew
Fedora also looks into moving to EGL with wxWidgets and GLEW.
If cmake is the vehicle for contemporary configuration and GNU make is stability-oriented, seems like that could be the best of both worlds?
After trying CMake and meson, I switched all my projects from Makefile/automake, etc to @mesonbuild. It's getting pretty mature. A list of some projects using it... cc @eli-schwartz
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)
Not directly.
Shared library dependencies are part of your library internals. Your library takes care of loading those dependencies as needed -- the applications using GLEW do not need to know about them.
But... they do need to worry about shared libraries from someone else being injected into the build, if those other libraries have "different symbols using the same name". So the worry here is not "the shared library dependencies" but rather just, "does some application use both libGLEW and libGL, and after this change it will use libGLEW->libOpenGL and libGL, and mixing libGL together with libOpenGL will cause the world to explode".
It's technically possible, but I was under the impression GLEW existed so that you don't need to mess with libGL yourself. Is that (directly linking to libGL and indirectly to libOpenGL) still a major concern, then?
Is it safe to assume anyone who has libOpenGL also has a libGL from the libglvnd project? That should be safe to mix libraries if they're both from libglvnd as the implementations are shared, right?
Does seem hostile to pester other projects away from GLEW. Just saying. I'm happy for them to make their choices for their own reasons, of course.
Does seem hostile to pester other projects away from GLEW. Just saying. I'm happy for them to make their choices for their own reasons, of course.
Additionally, there's no evidence I could find that Fedora is in the process of dropping GLEW. @cryptomilk stated in an issue opened on @MegaGlest
we are currently trying to get rid of GLEW in Fedora
Also stated was that GLEW isn't maintained anymore, which is obviously inaccurate.
I havn't actually had someone clearly say that their application is broken without a new GLEW release. Yes there are some build refinements and things, but the velocity of change in OpenGL seems a lot less than it used to be. Yes clearly it's been too long since a GLEW release, but I don't see GLEW going away just because someone got upset and went on a crusade. I'm quite happy for there to be alternatives, especially if those are less concerned with supporting really old stuff that ought to keep working. (In my opinion)
I havn't actually had someone clearly say that their application is broken without a new GLEW release.
Please take a look at it from a packaging perspective instead of an application perspective. There is packaging of glew and even of glew-egl: https://repology.org/projects/?search=glew "2.2.0" may mean entirely diffent things here.
In vcpkg, it is 2.2.0 + 4 patches. But HEAD is 2.2.0 + 59 commits (from 4 years). The options for vcpkg are to stick to the old version, patching minimally to keep it working, or to start ignoring the old version scheme and use date-based versioning instead. Which will break sorting when there is another release eventually. Without seeing how to move closer to HEAD in a sustainable way, upstreaming of patches isn't really encouraged.