Visual studio community 2017 LNK2019 unresolved external symbol - c++

I've been looking around for the whole day and I find no solution. Im using opengl extensions glew, glfw and glm. Visual Studio Community 2017 throws up the exception: Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol __imp__glewInit#0 referenced in function _main Name Directory.
My project is located: C:\Users\timbucktoo\Desktop\Projects\Scape\Scape
My extensions are located: C:\Users\timbucktoo\Desktop\Projects\Scape\Scape\OpenGL Exetensions Binaries\unzipped
I have the c++ include directories added: C:\Users\timbucktoo\Desktop\Projects\Scape\Scape\OpenGL Exetensions Binaries\unzipped\glm-0.9.8.4 %281%29\glm;
C:\Users\timbucktoo\Desktop\Projects\Scape\Scape\OpenGL Exetensions Binaries\unzipped\glfw-3.2.1.bin.WIN64\glfw-3.2.1.bin.WIN64\include;
C:\Users\timbucktoo\Desktop\Projects\Scape\Scape\OpenGL Exetensions Binaries\unzipped\glew-2.0.0-win32\glew-2.0.0\include;
I have the Linker general library directories added:
C:\Users\timbucktoo\Desktop\Projects\Scape\Scape\OpenGL Exetensions Binaries\unzipped\glew-2.0.0-win32\glew-2.0.0\lib\Release\x64;
Visual studio has told me I have a x86 machine, I am not fully aware of what this means but from what I have assumed this machine is running 64-bit windows.
I have tried mixing up all the options like the different add directories/libraries option and I can come up with no solution. This may have been asked before but not on the visual studio community 2017. Please help. THanks. :)
Oh and here is the code which I also tried using the pragma comment with glew32.lib.
#include <stdlib.h>
#include <stdio.h>
#include <GL\glew.h>
#include <GLFW\glfw3.h>
#include <glm\glm.hpp>
int main()
{
if (!glfwInit())
{
fprintf(stderr, "Failed to initialize GLFW\n");
return -1;
}
glfwWindowHint(GLFW_SAMPLES, 4); // 4x antialiasing
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); // We want OpenGL 3.3
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); // To make MacOS happy; should not be needed
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); //We don't want the old OpenGL
// Open a window and create its OpenGL context
GLFWwindow* window; // (In the accompanying source code, this variable is global)
window = glfwCreateWindow(1024, 768, "Tutorial 01", NULL, NULL);
if (window == NULL) {
fprintf(stderr, "Failed to open GLFW window. If you have an Intel GPU, they are not 3.3 compatible. Try the 2.1 version of the tutorials.\n");
glfwTerminate();
return -1;
}
glfwMakeContextCurrent(window); // Initialize GLEW
glewExperimental = true; // Needed in core profile
if (glewInit() != GLEW_OK) {
fprintf(stderr, "Failed to initialize GLEW\n");
return -1;
}
// Ensure we can capture the escape key being pressed below
glfwSetInputMode(window, GLFW_STICKY_KEYS, GL_TRUE);
do {
// Draw nothing, see you in tutorial 2 !
// Swap buffers
glfwSwapBuffers(window);
glfwPollEvents();
} // Check if the ESC key was pressed or the window was closed
while (glfwGetKey(window, GLFW_KEY_ESCAPE) != GLFW_PRESS &&
glfwWindowShouldClose(window) == 0);
}

LNK2019 unresolved external symbol __imp__glewInit#0 referenced in function _main
This tells you that it can't find the external symbol. Which is because you aren't linking glew32.lib.
As you're using MSVC / Visual Studio, try adding glew32.lib to your project directory. Then add glew32.lib under Project Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies. Since you're using MSVC you can also (as you already mentioned) add the following:
#pragma comment(lib, "glew32.lib")
If you have glew32.lib in your project directory and added the line above to your .cpp file. Then that linker error shouldn't come.
Now (given your example) just add something like glClear() and you then get something akin to:
LNK2019 unresolved external symbol __imp__glClear#4 referenced in function _main
Then that's because you also need to add opengl32.lib to your linker.
#pragma comment(lib, "opengl32.lib")
If you get a linker error like this:
LNK4272: library machine type 'X86' conflicts with target machine type 'x64'
It means that you're building for x64 but some of your libraries are built for x86. In other words you might be using the x64 version of glew32.lib, while you actually need to use the x86 version of glew32.lib.
If your code compiles but when the application is run you get something like:
The program can't start because glew32.dll is missing from your computer.
Then add the glew32.dll to your project directory.
Again version matter, so if the application crashes saying something like:
The application was unable to start correctly (0xc000007b)
Then like before your application might be built for x86, but the glew32.dll is the one built for x64.
Verify everything above, and it should compile and run.
Last but not least. Instead of using GLEW I highly recommend switching to GLAD instead. GLEW is old and broken and as far as I can tell not really supported anymore.
Additionally GLAD is way easier to setup and use. You go to the generator, select the version you want to target, press generate and download an implementation (.c) file and a few headers (.h). That's it. No libs to link against, no dll's to carry around or anything.
I have a x86 machine, I am not fully aware of what this means
x86 is an instruction set architecture. However x86 is more commonly used to refer to 32-bit. Whereas x64 is used to refer to 64-bit. The architecture is the same, it's just 64-bit instead of 32-bit. The 64-bit version of the x86 architecture is also called
x86-64 or AMD64.
This also means that a 64-bit CPU can execute 32-bit instructions. But a 32-bit CPU can't execute 64-bit instructions. Which is why applications usually target 32-bit computers.

Related

using lp_solve with visual studio 2015

I'm rather new to C++. I'm trying to use VS2015 and the lp_solve library(https://sourceforge.net/projects/lpsolve/files/lpsolve/5.5.2.5/) to solve my linear eq problem(for exact Gromov-Hausdorrf Distance, see https://mediatum.ub.tum.de/doc/1231885/1231885.pdf section 3.1 and 3.3). My machine is x64 system. Here is what I've done:
donwload the lp_solve_5.5.2.5_dev_win64.zip package and decompress it.
specific the library directoy(through project -> properties -> linker)
specific lib I used (liblpsolve55.lib and liblpsolve55d.lib for statically linking) through project->properties->linker->input->additional dependency.
declare the .h file directory(through project->properties->C/C++).
Here is what I declare in my code:
#include "lp_lib.h"
#pragma comment(lib, "liblpsolve55.lib") // static
#pragma comment(lib, "liblpsolve55d.lib") // static for debug
While when I run the code with x86, it will show the following problems:
error LNK2019: unresolved external symbol _make_lp#8 referenced in function "void __cdecl my_solve [totally 13 errors like this]
warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64' [totally 2 warnings like this]
While when I switch the runner with x64:
I got 550 errors, mainly due to the “dlfcn.h”: No such file or directory
in the lp_lib.h file, it has lines:
#if (LoadInverseLib == TRUE) || (LoadLanguageLib == TRUE)
#ifdef WIN32
#include <windows.h>
#else
#include <dlfcn.h>
#endif
#endif
which means it has treat me as a linux machine since dlfcn.h is for unix/linux
I've also try to use the 32bit version package(lp_solve_5.5.2.5_dev_win32.zip), but it do not work either.
with x86 runner:__iob, _printf issues.
with x64 runner:“dlfcn.h”: No such file or directory
I've successively build and run the demo in my mac with the corresponding package(lp_solve_5.5.2.5_dev_osx32.tar.gz). But I still want to know how to build and run it in VS2015.
Here I'll state what I do in mac if anyone need it(using Xcode).
download the lp_solve_5.5.2.5_dev_osx32.tar.gz package
add all the .h file in build phase -> headers
add the liblpsolve55.a file in build phase -> link binary with libraries
(if you want to use .dylib as dynamic linking, add it to the build phase -> copy file, but it do not work for me)
in build setting, set the Architectures to 32-bit intel
in build setting, set the Build Active Architecture Only to No
Thank you very much, actually nobody answer this question :) But I've solve the problem myself. Here is what I do for VS2015:
use package lp_solve_5.5.2.5_dev_win32.zip
add the .h file and .lib as above
change the run library, through properties -> C/C++ -> code generation -> run library -> change the DLL(/MDd) to (/MTd)
if you still got some fprintf issues, go to properties -> linker -> input -> additional dependency, and add : legacy_stdio_definitions.lib
That will be OK. That my be some translation issue, yes I use the chinese-version VS...

C++ SDL (Visual Studio 2015): cannot open file stddef.h

I'm relatively new to c++ and have been following the Lazy Foo' tutorial for installing SDL2 in visual studio 2010 (But I am using visual studio 2015).
I have followed the guide a couple of times now, so pretty certain I have incuded the right files etc. Here is a screen shot of my VC++ Directories settings:
#include <SDL.h>
#include <stdio.h>
int main(int argc, char* argv[]) {
SDL_Init(SDL_INIT_EVERYTHING);
SDL_Window *window = 0;
window = SDL_CreateWindow("SDL window",
SDL_WINDOWPOS_CENTERED,
SDL_WINDOWPOS_CENTERED,
640, 480,
SDL_WINDOW_SHOWN);
SDL_Delay(1000);
SDL_DestroyWindow(window);
SDL_Quit();
return 0;
}
When compiled (32 bit) I receive this error:
......\documents\sdl\sdl2-2.0.4\include\sdl_stdinc.h(50): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory
I also have the error "cannot open source file stdio.h" when hovering over the include statement for stdio.h
I'm going to continue to look at it all, but if anyone has any suggestions that would be greatly appreciated. Failing that I'll probably just install on Linux :)
Cheers and thanks for your time.
Suggestions: Use the dropdown, (inherit from parent or project defaults) to repair the visual c++ directories which you shouldn't ever edit.
Don't add it to the c++ directories, That's a weird idea. Add it to Configuration Properties > c/c++ > additional include directories. If you had done that, then you couldn't have possibly messed up the compiler. It's a lot simpler too. Just paste the one directory in there. That's what it's meant for.
Also Lazy Foo seems to only to have a VS2010 guide. Maybe I just couldn't find the VS2015 guide...
The error message
fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory
tends to happen when you're building your program with a version of MSVC different from the one used to build the library.
You should find out which version the SDL binaries were built with, and try using that. A newer MSVC might work, an older one might not.
You can always try building SDL yourself.

unresolved external symbol __imp__glewInit VS __imp__glewInit#0

When I use opengl in my program, I come acrross a problem when using "glew": unresolved external symbol _imp_glewInit (when use the glew 1.10.0), as I replace the glew32.lib by version "glew 1.6.0", this problem is solved. However, when I compile the attached simple code in a .cpp file, link step fails with an error: external symbol _imp_glewInit#0. Then I use VS2008's dumpin.exe to inspect glew32.lib in glew 1.6.0 and glew 1.10.0, it turns out glew 1.6.0 has a symbol named _glewInit while glew 1.10.0 has _glewInit#0.
So my question is why these two glew32.libs have different symbol names? If I want to use the new features in glew 1.10.0 and has the error "unresolved external symbol _imp_glewInit", what is the best way to solve it?
#include "glew.h"
#include <GL/freeglut.h>
int main(int argc, char **argv){
glutInit( &argc, argv );
glutInitDisplayMode( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH );
glutCreateWindow("123");
GLenum err = glewInit();
return 0;
}
PS: All my test is on Win7, the compiler is VS2008_SP1.
#0 is the name decoration scheme for a __stdcall function that is passed 0 bytes worth of arguments (in other words, a void function). Use the proper header that ships with your library so that it uses the calling convention the library was compiled with. In this case, whether you use C or C++ linkage (as suggested in comments) makes no difference because the __stdcall calling convention always adds the underscore at the beginning of the symbol name.
Regarding _imp_glewInit that is another matter entirely, as that is the DLL import stub. In the end, there is almost no real benefit to using the DLL version of GLEW. So I suggest you use the static linking version: glew32s.lib and define GLEW_STATIC to make things easier in the long-run.
To answer your final question: there are no new features in GLEW that you can use just by dropping in a new version of the DLL, your program has to be aware of the extensions GLEW loads when you actually write the code. If there is no code that takes advantage of one of the new extensions, then nothing is gained. This is why the DLL version of GLEW offers nothing special vs. the static library.

CGAL unresolved externals when compiling/linking on Windows

I'm getting strange (for me) errors during compiling a test program which uses some parts of the CGAL library.
First, the environment:
Windows 7 64 bits
Boost 1.53
CGAL 4.3
Qt 4.8.4
CMake 2.8.10.2
Visual Studio 2010 professional
I installed all the libraries for 32 bits (if this was an option during installation).
Installation wrong?
In order to install CGAL on my computer, I followed this tutorial: http://www.cgal.org/windows_installation.html. I have to note here that this did not work out-of-the-box for me. During the configuration phase of CGAL in CMake, the boost libraries were not found (although I set the corresponding environment variables, as stated in the tutorial). After setting the incorrect variables in CMake, I was able to complete the configuration and generation phase. After that, I was able to compile both the Debug as well as the Release configurations of CGAL in Visual Studio.
In order to test whether the CGAL lib was installed successfully, I tried to compile and run both the examples and demos. These also did not work immediately. The problem was that the CGAL and Boost headers (and binaries) were not found. After setting the right paths in Project properties => Configuration properties => C/C++ => Additional Include Directories and in Project properties => Configuration properties => Linker => Additional Library Directories the examples and demos could be build. I successfully ran these examples after that.
Actual problem
Now, I'm tyring to compile a simple program, in order to be able to make a certain exercise (http://acg.cs.tau.ac.il/courses/algorithmic-robotics/spring-2013/exercises/assignment-2 exercise 2.1). Here, there are two files supplied: basic_typdef.h and cgal_bootcamp.cpp
*basic_typedef.h*
#pragma once
#include <CGAL/Cartesian.h>
#include <CGAL/Gmpq.h>
#include <CGAL/Polygon_2.h>
#include <CGAL/Polygon_with_holes_2.h>
#include <CGAL/Boolean_set_operations_2/Gps_default_dcel.h>
#include <CGAL/Polygon_set_2.h>
#include <list>
/*******************************************************************************************
* This file contatins basic typedefs (from CGAL and more).
*******************************************************************************************/
typedef CGAL::Gmpq Number_type;
typedef CGAL::Cartesian<Number_type> Kernel;
typedef Kernel::Point_2 Point;
typedef CGAL::Polygon_2<Kernel> Polygon;
typedef CGAL::Polygon_with_holes_2<Kernel> Polygon_with_holes;
typedef CGAL::Polygon_set_2<Kernel> Polygon_set;
typedef std::list<Polygon_with_holes> Polygon_with_holes_container;
*cgal_bootcamp.cpp*
#include "basic_typedef.h"
int main(int argc, char* argv[])
{
return 0;
}
(For convenience I removed the comments in the file cgal_bootcamp.cpp)
With Visual Studio, I can compile the two files as above. However, when I try to create a Point (as defined in basic_typedef.h), I'm getting the (strange) errors:
#include "basic_typedef.h"
int main(int argc, char* argv[])
{
/*
1. Point
http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Kernel_23_ref/Class_Point_2.html
*/
// Create Point with the coordinates (0.5, 0.6)
Point p;
return 0;
}
The errors that occur:
Error 1 error LNK2019: unresolved external symbol __imp____gmpq_init referenced in function "public: __thiscall CGAL::Gmpq_rep::Gmpq_rep(void)" (??0Gmpq_rep#CGAL##QAE#XZ) C:\Dropbox\Capita Selecta\Assignments\Assignment 2.1\warmup-exercise\cgal_bootcamp.obj warmup-exercise
Error 2 error LNK2019: unresolved external symbol __imp____gmpq_clear referenced in function "public: __thiscall CGAL::Gmpq_rep::~Gmpq_rep(void)" (??1Gmpq_rep#CGAL##QAE#XZ) C:\Dropbox\Capita Selecta\Assignments\Assignment 2.1\warmup-exercise\cgal_bootcamp.obj warmup-exercise
Error 3 error LNK1120: 2 unresolved externals C:\Dropbox\Capita Selecta\Assignments\Assignment 2.1\warmup-exercise\Debug\warmup-exercise.exe 1 1 warmup-exercise
4 IntelliSense: #error directive: "Mixing a dll CGAL library with a static runtime is a really bad idea..." c:\dev\cgal-4.3\include\cgal\auto_link\auto_link.h 364 4
5 IntelliSense: #error directive: "some required macros where not defined (internal logic error)." c:\dev\cgal-4.3\include\cgal\auto_link\auto_link.h 397 4
I have no clue what is going wrong here (I have to note that I'm still a noob with C++). It seems that there is something wrong with the GMP library (at least the linking to this?) I found in another post that for someone there were no libgmp files build (can't find that post anymore), but that is not the case for me (I think): in CGAL-4.3/auxiliary/gmp/lib I see four files, libgmp-10.dll libgmp-10.lib libmpfr-4.dll and libmpfr-4.lib.
Also the error on line 4 points to something that might cause this error ("Mixing a dll CGAL library with a static runtime is a really bad idea..."), but I do not know what this actually means (or how I can resolve it).
Further, I tried to setup all the libraries on another computer, but I got the same errors there also.
Could anyone point me in the right direction to solve this problem? If you need more information, please let me know.
This comment answered the question: the script cgal_create_cmake_script can be used to create a CMake file that can be used to generate a correct Visual Studio project using CGAL.

Compiling Glew and SDL in C++ with Code::Blocks

I've spent the last 24 work hours trying to get this to compile, using multiple searches and tutorials (Some say I need to link it dynamically while others say I need to statically), I can not get this to work. I'm relatively new to compiling and linking so any help would be appreciated.
Here is my code(As you can tell by my comments I was very tired last night with coding this):
#define NO_SDL_GLEXT
#define GLEW_STATIC
#include "GL/glew.h"
#include "SDL/SDL.h"
#include "SDL/SDL_opengl.h"
int main (int argc, char* args[]){
//Loads the SDL video module
SDL_Init(SDL_INIT_VIDEO);
//Creates the SDL Surface for OpenGL to draw to
SDL_Surface* surface = SDL_SetVideoMode(800,600,32, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_OPENGL );
//Sets the caption...
SDL_WM_SetCaption("OpenGL",0);
glewExperimental = GL_TRUE;
glewInit();
//Main event loop, this is the BREAD AND BUTTER LADIES AND GENTLEMEN
SDL_Event windowEvent;
while (true){
if (SDL_PollEvent(&windowEvent)){
//If you close the appplication, causes it to actually stop running :D
if (windowEvent.type == SDL_QUIT) break;
//Close it with the ESC key! :D:D:D:D:D:D:D:D:D:
if (windowEvent.type == SDL_KEYUP && windowEvent.key.keysym.sym == SDLK_ESCAPE) break;
}
//Literally the one extra line of code needed to do double buffering
SDL_GL_SwapBuffers();
}
//I wish I knew what this ended...LOPE JK
SDL_Quit();
return 0;
}
And in the search directories I have:
Compiler:
E:\Programs\CodeBlocks\glew-1.10.0\include
E:\Programs\CodeBlocks\SDL-1.2.15\include
Linker:
E:\Programs\CodeBlocks\glew-1.10.0\lib\Release\x64
E:\Programs\CodeBlocks\SDL-1.2.15\lib
And finally in the Linker settings I have
Link libraries:
E:\Programs\CodeBlocks\glew-1.10.0\lib\Release\x64\glew32s.lib
Other linker options:
-lmingw32 -lglew32s -DGLEW_STATIC -lSDLmain -lSDL
The error I am currently getting is:
In function 'SDL_main':
undefined reference to `glewExperimental'
undefined reference to `glewInit#0'
Thank you in advance for all the help!
You are getting linker errors. It looks like you are compiling your application using the Mingw compiler. But, are you sure the glew library you are using was also built with/for Mingw? If you didn't build glew yourself and downloaded a prebuilt binary, it was most probably built using Visual Studio. Note that its not straightforward to mix libraries from different compilers like this.
Look at this:
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
P.S: Unless philosophical reasons against proprietary software is preventing you from doing so, you really ought to consider using Visual Studio compilers. The express editions of Visual Studio compilers are free (beer-like). You can use the Visual Studio compiler in really great IDEs like QtCreator.