Actually, I know it's a popular linking problem, which regularly can be resolved by adding #pragma(lib, "glu32.lib") or adding glu32.lib in Visual studio configuration.
However, my problem is strange and solutions above is useless.
I added some extra files containing OpenGL functions like gluPerspective and gluBuild2DMipmaps to the CUDA project, the VolumeRender, which is from CUDA SDK.
After compiling, I found those extra files would occur the Unresolved External Symbol error for glu functions. However, when I put these glu functions into the original Cpp file, it works fine.
I have ever tried two solutions above but useless. Could anyone give me a hint to solve this puzzle?
Finally I gave up. I tried to add the CUDA part into the OpenGL projects. It worked fine!
Related
I am implementing a SLAM-algorithm in Visual Studio 2019 where I want to use the ICP algorithm from the MRPT library for scan-matching.
I installed the MRPT library as 32-bit from source code using CMake. Problem is the error I'm receiving when building the solution (shown below). I assume it is because I have not added Additional Library Directories or Additional Dependencies for the Linker, because I can't find the .lib/.dll files anywhere. I tried installing the 64-bit precompiled binaries for Windows, where I found the .lib-files inside a lib-folder which does not appear when compiling manually with the source code - but can't use the same lib's because I need 32-bit (I tried linking to them, but the same error occurred in addition a bunch of warnings that library is 64-bit and target is 32-bit).
The code is pretty much exactly the same as the first example here, with (I believe) all necessary headers included.
The error produced (I also receive many more of the same error for every class I attempt to use from the library):
particle.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall mrpt::poses::CPose2D::CPose2D(double,double,double)" (__imp_??0CPose2D#poses#mrpt##QAE#NNN#Z) referenced in function (function)
The quick question is: Shouldn't the .lib/.dll files be produced when compiling from source code as well? Or is there something embedded in the library so I don't need them, in which case there must be something else wrong?
The more complicated question is: If the missing .dll/.lib-files is not the problem, what could it be?
Sorry if I am missing any relevant information, this is my first post. Just let me know and I will provide.
Any help is greatly appreciated!
I've got a C++ Builder (Rad Studio Berlin) project setup to use Direct2d. Canvas drawing works just fine with the TDirect2DCanvas which would indicate Direct2D is linking properly. Everything renders smoothly. However, I need to use a matrix. I get linking error when I try to. For example, when try I:
canvas->RenderTarget->SetTransform(D2D1::Matrix3x2F::Rotation(15.0, D2D1PointF(100, 100)));
...I get the following linking error:
[ilink32 Error] Error: Unresolved external 'D2D1MakeRotateMatrix' referenced from C:\DP\TRUNK\SRC\CLIENTSIDE\APPLICATIONS\VIEWER\WIN32\DEBUG\MIMAGE.OBJ
C++ builder was supposed to already be setup to link against direct2d if I just include the headers. Can anyone help me link against the appropriate files in the C++ Builder way?
I found the solution from a different source. Here it is:
After some research, this issue has not been determined to be a bug.
For many of the standard Windows API functions, the IDE will add the correct library automatically so that the dependencies on the function references will be satisfied. With DirectX (which is somewhat uncommonly used), the IDE does not automatically supply the library which corresponds to the header file, so this is causing the unresolved linker errors.
The solution is to either (as I mentioned previously) add the D2D1.lib to the project, or statically reference it in code:
// as long as D2D1.lib is on the library search path, it should be found
#pragma comment(lib,"D2D1.lib")
Some developers add the above line of code to their headers and so all you need to do is include the header and all is well... the DirectX team did not do this and hence the unresolved linker errors.
Hope this clarifies the issue,
I get the following error while trying to build a CUDA/C++ code in Visual Studio 2012. I'm using CUDA v5.0
1> Generating Code...
1>LINK : warning LNK4044: unrecognized option '/MLd'; ignored
1>cublas_device.lib(kepler_sm35_gemm_wrapper.obj) : error LNK2019: unresolved external symbol __cudaRegisterLinkedBinary_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f referenced in function "void __cdecl __sti____cudaRegisterAll_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f(void)" (?__sti____cudaRegisterAll_59_tmpxft_00001040_00000000_8_kepler_sm35_gemm_wrapper_cpp1_ii_9402ff4f##YAXXZ)
Anybody has any idea of where the problem might be? I've tried googling around, but haven't found a solution for this as yet.
Thanks a lot!
This article shows information about what the /MLd linker option does. It essentially has to do with multithreaded libs being loaded and the configuration of your project.
Is your (Debug) project set up to link with the microsoft linker or nvcc? (The error messages appear to be coming from the microsoft linker.) You may want to look at this question
Device code and device libraries (that you are linking against) need to be linked with nvcc.
You need to link against the debug version of the CUDA library. You try to compile in Debug mode, but then you link against a library which seems not to have been built in debug mode. Thus it gets all messed up.
So you should either get the .lib file for the debug version, or build it yourself if you have the source code. Then you link your debug build with the debug .lib and same for release.
Also, it may help that you use the same version of the compiler to build all libs, otherwise you may run into name mangling issues (which could be also a potential cause for your problem). It happened to me after switching to a newer VS version: I had to recompile all the .lib I was linking against.
It looks like some sort of using a external (extern) variable that isn't defined. The code is required for further information
I was able to fix it! I was linking to cublas_device.lib which was referring to an unresolved external symbol. However, this lib file wasn't required by my project, so just removing it from the linked files worked! However, in Release mode this error wasn't happening - maybe because this part of the code in cublas_device.lib was in the debug section.
In any case, since it is not required by my project, removing it solves the problem.
Thanks a lot for all your replies!
I encountered the same issue, Changing the Configuration Type from "Dynamic library (dll)" to "Static library (lib)" worked for me.
I've built an OpenGL program with my glu and gl header files default included in windows 7 professional edition. Now, I've bought a book that describes OpenGL game development. The author of this book said, I have to include the glew header into my project. After I've done this I got some unresolved external symbol errors.
So, now I'm really confused.
I've worked earlier with glBegin and glEnd statements in my program. Now I've to work with glBindBuffers and glGenBuffer etcetera, but I get the unresolved external symbol errors, like that:
1>cWindows.obj : error LNK2001: unresolved external symbol __imp___glewBindBuffer
1>cMdlLoader.obj : error LNK2001: unresolved external symbol __imp___glewBindBuffer
1>cMdlLoader.obj : error LNK2001: unresolved external symbol __imp___glewBufferData
1>cMdlLoader.obj : error LNK2001: unresolved external symbol __imp___glewGenBuffers
Is there anyone here who can explain the difference between these header files and what I have to do with them?
I goggled many times, but on different sites there are much more confusing words like "glee" or "glut".
You're mixing up 3 different things here:
OpenGL
the GL Utilities (GLU) which are not part of OpenGL
and the GL Extension Wrangler (GLEW)
GLEW and GLU are completely different things and you can not replace one with another.
GL/gl.h are the base OpenGL headers, which give you OpenGL-1.1 function and token declarations, any maybe more. For anything going beyond version 1.1 you must use the OpenGL extension mechanism. Since this is a boring and tedious task, that has been automatized by the GLEW project, which offer all the dirty details packed up in a easy to use library. The declarations of this library are found in the header file GL/glew.h. Since OpenGL extensions don't make sense without basic OpenGL, the GLEW header implicitly includes the regular OpenGL header, so as of including GL/glew.h you no longer need to include GL/gl.h.
Then there's GLU, a set of convenience methods, which BTW are seriously outdated and should not be used in any modern OpenGL program. There's no modern GLU, so just forget about it. Anyway, it's declarations are made available by the header GL/glu.h (the one you were asking about).
The errors you get have nothing to do with include files though. Those are linker errors. Just including the declarations is only half of the job. The other half is linking the actual definitions and those are not in the header by the library file; libglew.so or libglew.a on a *nix OS, glew.lib or glew32.lib or glews.lib or glew32s.lib on Windows. If not using the static versions (those without the 's') you also must have installed the right DLL.
So to use GLEW you need to include the header and add it to the list of libraries in the linker options. Also you must call glewInit(); once you've obtained a OpenGL context in your program.
gl: This is the base header file for OpenGL version 1.1. That means if you want to use any functionality beyond version 1.1, you have to add any extension library on this.
glew: OpenGL Extension Wrangler Library. This is a cross-platform library for loading OpenGL extended functionality. When you initialize this library, it will check your platform and graphic card at run-time to know what functionality can be used in your program.
glu: This is OpenGL utilities library, which has been not updated for long time. Don't need to use this header file.
glut: OpenGL Utility Toolkit for Windowing API. This is good for small to medium size OpenGL program. If you need more sophisticated windowing libraries, use native window system toolkits like GTK or Qt for linux machines.
glfw: OpenGL Frame Work. Another multi-platform library for creating windows and handling events. FreeGlut can be used as an alternative. glfw is designed for game development.
glm: OpenGL Mathematics. It helps implementing vectors and matrices operations.
I am very new to OpenGL stuff, so please correct me if I'm wrong.
I am following along with tutorials on the site, http://openglbook.com/, and I have run into a problem I cannot solve. In the second tutorial, they begin using shaders. After entering in their code, I get linking errors such as,
"[Linker error] undefined reference to '_ imp____glewGenVertexArrarys'"
as well as a lot of others. My development environment is Dev-C++. I have linked against glew32.lib, but it still fails to recognize some of the GLEW functions. I have been able to utilize some functions from the GLEW library, but when it comes to these shaders, something is going wrong and I cannot figure out why. Any help would be much appreciated.
I recently had a similar problem with glew and VS 2010.
I can't remember the link that said it but I think they talked about statically linking glew by defining the makro GLEW_STATIC.
Btw for me the solution was to recompile GLEW from source on my own.
EDIT
I think I found the link: http://www.gamedev.net/topic/462433-glew-and-mingw/