cmake: Cannot build glew32d.dll with Visual Studio 2015

[kyuur]

Build files generated with CMake and then ALL_BUILD (or just glew) built in Debug.

1>------ Build started: Project: glew, Configuration: Debug Win32 ------
1>     Creating library C:/Users/robky/Documents/Development/Libraries/build/glew-2.0.0/lib/Debug/glew32d.lib and object C:/Users/robky/Documents/Development/Libraries/build/glew-2.0.0/lib/Debug/glew32d.exp
1>glew.obj : error LNK2019: unresolved external symbol @_RTC_CheckStackVars@8 referenced in function _glewIsSupported@4
1>glew.obj : error LNK2019: unresolved external symbol __RTC_CheckEsp referenced in function _glewInit@0
1>glew.obj : error LNK2001: unresolved external symbol __RTC_InitBase
1>glew.obj : error LNK2001: unresolved external symbol __RTC_Shutdown
1>C:\Users\robky\Documents\Development\Libraries\build\glew-2.0.0\bin\Debug\glew32d.dll : fatal error LNK1120: 4 unresolved externals
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

Everything else builds without a problem.

It seems that this can be resolved in the following ways:

• Simply set Basic Runtime Checks (Project Configuration > C/C++ > Code Generation) to default, probably not the best idea for the debug target.
• Link additional debug CRT libraries. The project compile options are set up for the dynamic libraries but static works just fine too.
• Remove the "nodefaultlib" link option, although this causes a whole whack of other errors that make this unattractive.

[nigels-com]

On Visual Studio 2013 the /RTC1 flag is being used for glew32.dll. I'd recommend disabling "Configuration Properties - C/C++ - Code Generation - Basic Runtime Checks" rather than messing with exotic link libraries. Can the cmake config be adjusted to resolve this?

[undisputed-seraphim]

In the generated VS2015 solution files, under the settings for the glew project (not glew_s), under Linker -> Settings, I removed the entries

-BASE:0x62AA0000 -nodefaultlib -noentry

And the entire solution builds fine. I did this on the glew-2.0.0 tag. Lines 98 and 103 in this cmake file are the offending lines that adds these entries. What do they do? If they are no longer necessary, perhaps it can be removed.

My environment: Windows 8.1, Visual Studio 2015. Command: cmake .. -G "Visual Studio 14 2015 Win64"

[dschreij]

Line 103 target_link_libraries (glew LINK_PRIVATE -nodefaultlib -noentry) causes problems for me too when using Visual Studio 2008 to compile this project. It results in the following error:

Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target glew
[  8%] Building C object CMakeFiles/glew.dir/C_/Users/Daniel/OneDrive/src/glew-2.0.0/src/glew.c.obj
glew.c
[ 16%] Building RC object CMakeFiles/glew.dir/C_/Users/Daniel/OneDrive/src/glew-2.0.0/build/glew.rc.res
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation.  All rights reserved.

[ 25%] Linking C shared library bin\glew32.dll
   Creating library lib\glew32.lib and object lib\glew32.exp
glew.c.obj : error LNK2019: unresolved external symbol memset referenced in function glewContextInit
bin\glew32.dll : fatal error LNK1120: 1 unresolved externals
LINK failed. with 1120

the /nodefaultlib flag apparently also causes it to not find the memset() function any longer. Commenting line 103 makes the project compile in both VS2008 and VS2015 without problems!

In Visual Studio 2015 everything works perfectly with line 103 present though.

[nigels-com]

I'll go ahead and replace the memset call, in this case. I guess for other toolchains it's inlined.

[nigels-com]

@dschreij can you confirm that it's the official release of GLEW 2.0.0 that has this issue?

[nigels-com]

Linux and Mac look clean:

$ nm lib/libGLEW.a | grep -v ' r ' | grep -v '__GL' | grep -v '__glew'

glew.o:
0000000000000000 B glewExperimental
00000000000105a0 T glewGetErrorString
000000000000e9c0 T glewGetExtension
00000000000105c0 T glewGetString
00000000000105e0 T glewInit
0000000000018e00 T glewIsSupported
                 U _GLOBAL_OFFSET_TABLE_
000000000000e9e0 T glxewGetExtension
000000000000ea50 T glxewInit
0000000000020220 T glxewIsSupported
                 U glXGetClientString
                 U glXGetProcAddressARB
                 U glXQueryVersion

$ nm -gU lib/libGLEW.a | grep -v __glew | grep -v ___GLEW

lib/libGLEW.a(glew.o):
0000000000000000 T _NSGLGetProcAddress
00000000000343f7 S _glewExperimental
000000000000006f T _glewGetErrorString
000000000000004c T _glewGetExtension
000000000000008e T _glewGetString
00000000000000aa T _glewInit
00000000000000b4 T _glewIsSupported

[dschreij]

Yes, I tried with both the release tagged glew2.0.0 on Github, and the one from sourceforge.