error LNK1120: 1 unresolved externals ...-2.1.0\bin\Release\x64\glew32.dll glew_shared

[av-user]

It is only possible to build debug binary (32 & 64). I get the above error in VS 2010 while trying to build release.

[nigels-com]

Can you include here some more of the build log?

[av-user]

yes, of course.

1>------ Build started: Project: glew_static, Configuration: Release x64 ------
2>------ Build started: Project: glew_shared, Configuration: Release x64 ------
1>  glew.c
2>  glew.c
1>  glew_static.vcxproj -> D:\me\Projects\OpenGL\glew-2.1.0\build\vc10\../../lib\Release\x64\glew32s.lib
3>------ Build started: Project: glewinfo, Configuration: Release x64 ------
4>------ Build started: Project: visualinfo, Configuration: Release x64 ------
2>     Creating library ../../lib\Release\x64\glew32.lib and object ../../lib\Release\x64\glew32.exp
2>glew.obj : error LNK2019: unresolved external symbol memset referenced in function glewContextInit
2>../../bin\Release\x64\glew32.dll : fatal error LNK1120: 1 unresolved externals
3>  glewinfo.c
4>  visualinfo.c
4>  visualinfo.vcxproj -> D:\me\Projects\OpenGL\glew-2.1.0\build\vc10\../../bin\Release\x64\visualinfo.exe
3>  glewinfo.vcxproj -> D:\me\Projects\OpenGL\glew-2.1.0\build\vc10\../../bin\Release\x64\glewinfo.exe
========== Build: 3 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[nigels-com]

Ah, the memset dependency.

I do vaguely recall some discussion of C library dependencies that are flags-dependent on Windows compilers.

Are you using cmake, or the bundled projects?

[pancakeL]

I have the same problem too.It says "glew32.dll is not a valuabl Win32 program“ How can I fix this?

[ssrobins]

When I build with glew 2.1.0 (https://github.com/nigels-com/glew/releases/tag/glew-2.1.0)

Using this environment environment: MSVC 14.22.27905 (Comes with VS2019 16.2) CMake 3.15.1 Windows 10 Pro 64-bit 1809

With these build settings: Win32 x86 Release config

I too get the error LNK2001: unresolved external symbol _memset error.

I have a repo the makes a Conan package for glew: https://gitlab.com/ssrobins/conan-glew

Here's the full output of the build: https://gitlab.com/ssrobins/conan-glew/-/jobs/265529661

It was previously building with MSVC 19.21.27702.2, which came with VS2019 16.1: https://gitlab.com/ssrobins/conan-glew/-/jobs/250959339

I'm not using the shared lib, only the static one and I didn't want to go through the additional changes to add a CMake option to exclude the shared library build completely, though I'd love such a feature. So I just patched the CMakeLists.txt file to stop setting -nodefaultlib and -noentry: https://gitlab.com/ssrobins/conan-glew/blob/stable/CMakeLists.diff

Now it builds.

[nigels-com]

There seems to be more to this than nodefaultlib and noentry:

Same problem of x64 release DLL target with:

-     <IgnoreAllDefaultLibraries>true</IgnoreAllDefaultLibraries>
-      <NoEntryPoint>true</NoEntryPoint>
+      <IgnoreAllDefaultLibraries>false</IgnoreAllDefaultLibraries>
+      <NoEntryPoint>false</NoEntryPoint>

[nigels-com]

Seems to be specific to v142 toolchain with optimisation enabled.

v141 seems fine. (Visual Studio 2017)

[nigels-com]

Looks this compiler feature/bug has been around for a good while:

https://social.msdn.microsoft.com/Forums/en-US/a51fe950-cd74-4133-8d84-1bc07b353bc2/msvc-2005-automatically-calling-memset

I pushed some fixes for the vc15 solution that seem to work fine for all v141/v142, debug/release and 32/64.

That unblocks me for the purpose of a GLEW 2.2.0 release, but I'll also take a look at making cmake great again, also.

[nigels-com]

Pushed a cmake fix also.

If anyone can confirm on their side, that would be appreciated.

Thanks for the report.

[ssrobins]

When trying to build with cmake using the latest from master, I get an error saying it can't find include/GL/wglew.h. Looks like the entire include directory is no longer there.

[nigels-com]

There is a fresh snapshot, if that helps. https://sourceforge.net/projects/glew/files/glew/snapshots/glew-20190928.tgz/download

[ssrobins]

Built using CMake from the snapshot on Windows, Linux, and macOS, works fine!

[nigels-com]

Thanks for the confirmation.

[argltuc]

I tried do Built the snapshot under VS2010 as x64 with cmake and this result: Debug: glew -> FAILED => could not found libvcruntime.lib glew_s -> SUCCEED glewinfo -> FAILED => could not found glew32d.lib (of course) visualinfo -> FAILED => could not found glew32d.lib (of course)

Relese: glew -> FAILED => could not found libvcruntime.lib glew_s -> SUCCEED glewinfo -> FAILED => could not found glew32.lib (of course) visualinfo -> FAILED => could not found glew32.lib (of course)

If I use the preconfigurated VC10 solution, i get the again the arror, that memset is unresolved

If I remove by hand libvcruntime from the VS 2010 solution config for glew then it will build... but will it also run?......

[nigels-com]

If you can modify the bundled VC10 to make it happy, I'd be happy to incorporate that fix. I'm not sure I can install VC10 on my Windows 10 laptop, or if I have headroom to do so.

Thanks,

Nigel

[argltuc]

for now i have to postponed it, but it seems, that if you used /NODEFAULTLIB then msvcrt.lib has to be added as additional lib in VC10. This was my very quickly tested solution right now. I will check it in detail next week.

[nigels-com]

Thanks. That sounds about right. The general idea was to dodge the msvcrt runtime dependency, if I recall. But clearly that's not viable for certain toolchains.