-
Notifications
You must be signed in to change notification settings - Fork 0
Test update #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Test update #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…upported MX configurations from Visual Studio projects.
…a dummy DLL entry to avoid crashes.
included using CMake.
CMake 2.8.5 added the GNUInstallDirs module, which provides various variables following the CMAKE_INSTALL_*DIR pattern to allow users a more flexible installation setup and to provide sensible defaults while respecting distribution specific install locations like lib64 for RPM based linux distributions or debian multiarch tuples.
Install MSVC program database when building `Debug` or `RelWithDebInfo` configuration
Installing the library fails on macOS 12, if we use the compiler flags for the i386 architecture. See also: - nigels-com/glew#348 (comment)
Failure caused by `llvm-rc` failing on non-ASCII code point for copyright symbol.
Resolves #349 (I think)
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.
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
Instead of just removing periods and digits from SYSTEM, remove periods and digits and everything after any digits. This handles unusual system identifiers like powerpc-apple-darwin10.0.0d2. I wasn't sure if periods can appear anywhere other than in the release number so I retained the previous behavior of removing all periods regardless where they are.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.