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.
