Using cmake (version 3.23.0) the build fails to link the utils
```
[...]
[ 87%] Linking C executable bin/visualinfo [113/5249]
/usr/x86_64-pc-linux-gnu/bin/cmake -E cmake_link_script CMakeFiles/visualinfo.dir/link.txt --verbose=1
/usr/host/bin/x86_64-pc-linux-gnu-cc -Wall -g -ggdb3 -O0 -rdynamic CMakeFiles/visualinfo.dir/home/marv/scm/github/glew/src/visualinfo.c.o -o bin/visualinfo -Wl,-rpath,/h
ome/marv/scm/github/glew/build-obj/lib: lib/libGLEW.so.2.2.0 -lSM -lICE -lX11 -lXext -lOpenGL -lSM -lICE -lX11 -lXext
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: CMakeFiles/visualinfo.dir/home/marv/scm/github/glew/src/visualinfo.c.o: in function `main':
/home/marv/scm/github/glew/src/visualinfo.c:198: undefined reference to `glXQueryExtensionsString'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: CMakeFiles/visualinfo.dir/home/marv/scm/github/glew/src/visualinfo.c.o: in function `CreateContext':
/home/marv/scm/github/glew/src/visualinfo.c:1204: undefined reference to `glXQueryExtension'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: /home/marv/scm/github/glew/src/visualinfo.c:1206: undefined reference to `glXChooseVisual'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: /home/marv/scm/github/glew/src/visualinfo.c:1209: undefined reference to `glXCreateContext'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: /home/marv/scm/github/glew/src/visualinfo.c:1221: undefined reference to `glXMakeCurrent'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: CMakeFiles/visualinfo.dir/home/marv/scm/github/glew/src/visualinfo.c.o: in function `DestroyContext':
/home/marv/scm/github/glew/src/visualinfo.c:1227: undefined reference to `glXDestroyContext'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: lib/libGLEW.so.2.2.0: undefined reference to `glXGetProcAddressARB'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: lib/libGLEW.so.2.2.0: undefined reference to `glXQueryVersion'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: lib/libGLEW.so.2.2.0: undefined reference to `glXGetClientString'
collect2: error: ld returned 1 exit status
```
Commit 2b50f4a ("CMake: Prefer GLVND if available") changed the cmake
policy CMP0072 to `NEW` in order to make the FindOpenGL module prefer the
GLVND libraries (libOpenGL and libGLX) over the legacy GL library (libGL).
The help of the CMP0072 policy states:
> CMP0072
> -------
>
> .. versionadded:: 3.11
>
> ``FindOpenGL`` prefers GLVND by default when available.
>
> The ``FindOpenGL`` module provides an ``OpenGL::GL`` target and an
> ``OPENGL_LIBRARIES`` variable for projects to use for legacy GL interfaces.
> When both a legacy GL library (e.g. ``libGL.so``) and GLVND libraries
> for OpenGL and GLX (e.g. ``libOpenGL.so`` and ``libGLX.so``) are available,
> the module must choose between them. It documents an ``OpenGL_GL_PREFERENCE``
> variable that can be used to specify an explicit preference. When no such
> preference is set, the module must choose a default preference.
>
> CMake 3.11 and above prefer to choose GLVND libraries. This policy provides
> compatibility with projects that expect the legacy GL library to be used.
>
> The ``OLD`` behavior for this policy is to set ``OpenGL_GL_PREFERENCE`` to
> ``LEGACY``. The ``NEW`` behavior for this policy is to set
> ``OpenGL_GL_PREFERENCE`` to ``GLVND``.
>
> This policy was introduced in CMake version 3.11. CMake version
> 3.23.0 warns when the policy is not set and uses ``OLD`` behavior.
> Use the ``cmake_policy()`` command to set it to ``OLD`` or ``NEW``
> explicitly.
>
> .. note::
> The ``OLD`` behavior of a policy is
> ``deprecated by definition``
> and may be removed in a future version of CMake.
The changes from the mentioned commit combined with the new behaviour of
the FindOpenGL module resulted in the glew library being linked against
`libOpenGL` instead of `libGL`, but not `libGLX`. Since `libOpenGL`
doesn't link against GLX compared to `libGL` the linker errors above
surfaced. Fix this by explicitly linking against libGLX if GLEW_X11 is
enabled
I think this code tried to check for a zero terminated null byte, but it
actually just checked if the address of the corresponding character is
non-zero, which is always true. These broken checks are simply dropped
because the following code assumes that the string `b` doesn't include a
null byte and all call sites already pass the length of the string
without counting the null byte.
This bug was found by gcc 12.1 which emits a warning on this kind of
code. Now glew builds without any warnings using gcc 12.1. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103 for the
corresponding issue.
As discussed in Issue #310 stripping the binaries is
done by the link targets, not needed for the install step.
Along the lines of a Yocto batch by Ross Burton <ross.burton@intel.com>
The current rule for the binaries is:
glew.bin: glew.lib bin bin/$(GLEWINFO.BIN) bin/$(VISUALINFO.BIN)
In parallel builds, all of those targets happen at the same time. This
means that 'bin' can happen *after* 'bin/$(GLEWINFO.BIN)', which is a
problem as the 'bin' target's responsibility is to create the directory
that the other target writes into.
Solve this by not having a separate 'create directory' target which is
fundamentally racy, and simply mkdir in each target which writes into it.
Raw open should be avoided to prevent that in case of an exception
the file is not closed.
This also has the advantage that if the user forgets to call close
the file is still closed.
