Building Examples on Windows: GLEW on MSVC -- Linker errors

[Gonzalo Garramuño]

I have glew2.2.0 win64 downloaded from:

https://sourceforge.net/projects/glew/files/glew/2.2.0/glew-2.2.0-win32.zip/download

I unzipped it and the location of the x64 builds is in:

D:/code/lib/glew-2.2.0/bin/Release/x64
D:/code/lib/glew-2.2.0/lib/Release/x64

I moved the .lib and .dlls to the main directories (standard MSVC dirs):

cd D:/code/lib/glew-2.2.0/bin/Release/x64
mv *.dll ../..

cd D:/code/lib/glew-2.2.0/lib/Release/x64
mv *.lib ../..

I had to call cmake with all this (this needs work in the CMakeLists files):

cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release
-DCMAKE_PREFIX_PATH=D:/code/lib/glew-2.2.0 -DFLTK_BUILD_EXAMPLES=ON
-DCMAKE_CXX_FLAGS=-ID:/code/lib/glew-2.2.0/include

CMake does find glew32.
CMake compiles properly.

CMake does not link properly with the glew32.lib (DLL), getting errors
like (maybe I am missing a preprocessor definition of the OpenGL3test is
missing #include "windows.h"?

LINK: command
"C:\PROGRA~1\MICROS~1\2022\COMMUN~1\VC\Tools\MSVC\1439~1.335\bin\Hostx64\x64\link.exe
/nologo examples\CMakeFiles\OpenGL3test.dir\OpenGL3test.cxx.obj
/out:bin\examples\OpenGL3test.exe /implib:bin\examples\OpenGL3test.lib
/pdb:bin\examples\OpenGL3test.pdb /version:0.0 /machine:x64
/INCREMENTAL:NO /subsystem:windows
-LIBPATH:D:\code\applications\mrv2\BUILD-Msys-amd64\Release\FLTK-prefix\src\FLTK\build\src\..\lib
lib\fltk_gl.lib D:\code\lib\glew-2.2.0\lib\glew32.lib opengl32.lib
glu32.lib lib\fltk.lib comctl32.lib ws2_32.lib gdiplus.lib kernel32.lib
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib comdlg32.lib advapi32.lib /MANIFEST
/MANIFESTFILE:bin\examples\OpenGL3test.exe.manifest" failed (exit code
1120) with the following output:
OpenGL3test.cxx.obj : error LNK2019: símbolo externo __glewBindBuffer
sin resolver al que se hace referencia en la función "public: virtual
void __cdecl SimpleGL3Window::draw(void)" (?draw@SimpleGL3Window@@UEAAXXZ)

I modified FLTK's CMake files:

diff --git a/CMake/resources.cmake b/CMake/resources.cmake
index e5d6f8c9f..e755f89db 100644
--- a/CMake/resources.cmake
+++ b/CMake/resources.cmake
@@ -152,7 +152,7 @@ endif((NOT APPLE) OR FLTK_BACKEND_X11)
 find_library(LIB_freetype freetype)
 find_library(LIB_GL GL)
 find_library(LIB_MesaGL MesaGL)
-find_library(LIB_GLEW NAMES GLEW glew32)
+find_library(LIB_GLEW NAMES GLEW glew32s glew32)
 find_library(LIB_jpeg jpeg)
 find_library(LIB_png png)
 find_library(LIB_zlib z)

And with the static lib it linked properly.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

On 4/25/2024 6:50 AM, Gonzalo Garramuño wrote:
> I modified FLTK's CMake files:
>
> diff --git a/CMake/resources.cmake b/CMake/resources.cmake
> index e5d6f8c9f..e755f89db 100644
> --- a/CMake/resources.cmake
> +++ b/CMake/resources.cmake
> @@ -152,7 +152,7 @@ endif((NOT APPLE) OR FLTK_BACKEND_X11)
>  find_library(LIB_freetype freetype)
>  find_library(LIB_GL GL)
>  find_library(LIB_MesaGL MesaGL)
> -find_library(LIB_GLEW NAMES GLEW glew32)
> +find_library(LIB_GLEW NAMES GLEW glew32s glew32)
>  find_library(LIB_jpeg jpeg)
>  find_library(LIB_png png)
>  find_library(LIB_zlib z)
>
> And with the static lib it linked properly.
>

BTW, Albretch, there is a:

find_package(GLEW)

that looks in all the logical places and handles GLEW static and dynamic
libs nicely.

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

Hi Gonzalo,

thanks for the report, for your workaround, and the follow-up with the
hint to `find_package(GLEW)`. I looked into it (FindGLEW.cmake) and it
offers CMake targets for both the static lib and the DLL, depending on a
CMake variable and presence of the lib files.

[top-posting intentionally]

Please open a GitHub Issue for this report so it doesn't get lost. I'm
aware that there's another pending issue from you but you're currently
finding issues faster than I can fix them, particularly since I'm
working on other tasks as well.

TIA, Albrecht

PS: I noticed that your workaround would prefer the static GLEW lib
(glew32s.lib) rather than the DLL (glew32.lib), if it was applied this
way. The correct (or better, more variable) dealing with this situation
needs some investigation, see my note above.