unresolved external symbol __imp__glewInit VS __imp__glewInit#0 - c++

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.

Related

Visual studio community 2017 LNK2019 unresolved external symbol

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.

C++ - Linking third library functions in static library

I'm creating an C++ static library with code::blocks that call functions of the SDL library. The library compiles OK. I created annother project that will use the library I've created, all the build options are OK, I set the linker to work with the SDL and everything else, but, when I try to compile the project, I got Undefined Reference in the SDL functions. I solve this trouble by putting an call to SDL_Delay(1) function in the end of the main function.
It seems that the linker only found the SDL functions when I call at least one of them in the project that I'm compiling. Exist an more correct way to solve this?­
example:
#include "HW_Engine" // My static link library
void main(int argc, char *argv[]){
HWE_Core *Engine_Core = new HWE_Core(); // this constructor calls some SDL functions
...
SDL_Delay(1); // If I omit this, I have an Undefined reference for all the
// SDL functions called in the HW_Engine library
}
thanks for the help!

How to force the visual studio to use the wmain instead of main

I'm in need of parsing unicode parameters, so I wanted to use the wmain instead.
So instead of
int main(int argc, char** argv)
I would like to use
int wmain(int argc, wchar_t** argv)
The problem is that the visual studio is not recognizing the wmain, and it is trying to use main instead:
error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup
This is what I tried:
Changing the Properties->General->Character set
Changing the Entry point (In this case I got lot of compatibility errors with libraries that don't even have entry point, so it can't be specified there).
warning LNK4258: directive '/ENTRY:mainCRTStartup' not compatible with switch '/ENTRY:mainWCRTStartup'; ignored
Tried the _tmain instead, just to find out it is just a macro that changes it to main.
Using the #pragma comment(linker, "/SUBSYSTEM:CONSOLE /ENTRY:mainCRTStartup")
Using the UNICODE macro
Nothing helps.
Edit:
I would like to mention, that I'm using the vs120_xp (Win xp compatibile) toolset, but when I tried to use the default one, it still didn't work.
Edit2:
I tried to make brand new project, and the wmain worked there out of the box. I didn't have to change anything, so it have to be some specific setting in the current project that is causing it.
Using the #pragma comment(linker, "/SUBSYSTEM:CONSOLE /ENTRY:mainCRTStartup")
You are getting close, not quite close enough. The CRT has four entrypoints:
mainCRTStartup => calls main(), the entrypoint for console mode apps
wmainCRTStartup => calls wmain(), as above but the Unicode version
WinMainCRTStartup => calls WinMain(), the entrypoint for native Windows apps
wWinMainCRTStartup => calls wWinMain(), as above but the Unicode version
So it is /ENTRY:wmainCRTStartup
Do beware that the command line arguments are converted to Unicode assuming the default console code page. Which is a bit unpredictable, it is the legacy 437 OEM code page only in Western Europe and the Americas. The user might need to use the CHCP command (CHange Code Page) and tinker with the console window font to keep you happy. YMMV.
I was merging the differences between new project that was working properly and our project for hours until I found out that the problem is caused by our misconfiguration of the allegro preprocesor definitions.
Deep down in the allegro library in win/alconfig.h, there are these lines
#ifndef ALLEGRO_NO_MAGIC_MAIN
#if defined _MSC_VER && !defined ALLEGRO_LIB_BUILD
#pragma comment(linker,"/ENTRY:mainCRTStartup")
#endif
#endif
We did setup this macro for the allegro library compilation, but the allegro file was also included from the main project, that didn't specify this one.
Defining the macro in the main project fixed the problem (obviously).
I didn't really see this comming!

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.

why I can't use normal C++ classes with Qt

Can anyone pls tell me that, why I can't use normal C++ classes within a Qt programme. If there is any class which aren't inherited from QObject the compiler give me a linking error called,
error LNK2019: unresolved external symbol _main referenced in function _WinMain#16
I'm using Qt 4.5.2 (compiled by myself) with vs2005. Pls help me to solve this !
Edit:
Example...
//UnitManager.h
class UnitManager
{
public:
//-Some code
};
//CivilizationViewer.h
class CivilizationViewer : public QMainWindow
{
Q_OBJECT
//-some code
};
//main
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
CivilizationViewer w;
w.show();
return a.exec();
}
If I include UnitManager.h in CivilizationViewer.h compiler will give me that error. (eventhough I include UnitManager.h in main.cpp compiler will give me the error)
The error you gave doesn't have anything to do with what classes you're using. It looks like it's related to the entry point you have set for your application. Usually you want to use main() instead of WinMain() in Qt programs. Make sure your configuration is set up right.
You included a little bit of code in your question. Is that everything? If so, you're missing a main function.
Thanks for everyone. I found the error.
There is SDL.h in the UnitManager.h, so I have to add SDL.lib and SDLmain.lib (it is correct, right ?) then there is another definition for main in SDLmain.lib. So, there was a coflict between definitions of main. Therefore I added SDLmain.lib before adding qtmaind.lib. Then the problem solved by only giving a warning called,
warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
What is that warning ? I can just ignore the warning, but I like to get to know it ! Thanks
It seems like you need to link with qtmain.lib (qtmaind.lib for debug builds).
That library provides a WinMain function which is needed if you declared /subsystem:windows.
Source: http://lists.trolltech.com/qt-interest/2005-12/thread00170-0.html
It looks like you're not including the QT libraries properly... (the actual .lib file)
I think you actually made a win32 app.
try replacing your main for:
int _tmain(int argc, _TCHAR* argv[]){
your code
}
Seeing your error msg, i wouldn't guess Qt was your problem.
Did you install the Visual Studio Qt integration? Try it and make a new Qt project.