When compiling a win32 console project with GLFW in Visual Studio 2010 SP1, I am getting the following warning for debug configuration:
Warnung 1 warning LNK4099: PDB "vc100.pdb" wurde nicht mit "GLFW.lib(enable.obj)" oder an "C:\path-to-project with-spaces\World\Debug\vc100.pdb" gefunden; Objekt wird verknüpft, als ob keine Debuginformationen vorhanden wären. C:\path-to-project with-spaces\World\World\GLFW.lib(enable.obj) World
13 more for GLFW.lib(enable.obj), GLFW.lib(glext.obj), GLFW.lib(image.obj), GLFW.lib(init.obj), GLFW.lib(input.obj), GLFW.lib(stream.obj), GLFW.lib(tga.obj), GLFW.lib(win32_enable.obj), GLFW.lib(win32_fullscreen.obj), GLFW.lib(win32_glext.obj), GLFW.lib(win32_init.obj), GLFW.lib(win32_time.obj), GLFW.lib(win32_window.obj), GLFW.lib(window.obj)
And last but not least:
Fehler 15 error LNK1104: Datei "C:\path-to-project with-spaces\World\Debug\World.exe" kann nicht geöffnet werden. C:\path-to-project with-spaces\World\World\LINK World
The release configuration is compiling. This is probably still not enough information for solving my problem, but I would appreciate an explanation for why this can happen.
I don't know what the warnings/errors are saying because I don't know any German whatsoever, but generally if something compiles/links for release but not debug (or vice-versa) this means you're linking to the wrong libraries for the one that isn't working. Are there specific debug libraries (.dll's or .lib's) for the GLFW library? Sometimes you have to tell VS to use one for your project's release configuration and a different one for your project's debug configuration. Check for something like glfw.lib and glfw_d.lib, where the _d would indicate the debug library.
Or if you could supply the English translation of the link warnings/errors I might be able to help more.
Good luck!
Whenever building a project with VC++ fails, it's best to consult the MSDN with the error code. In your case http://msdn.microsoft.com/en-en/library/b7whw3f3(v=vs.80).aspx
Linker Tools Warning LNK4099 PDB 'filename' was not found with
'object/library' or at 'path'; linking object as if no debug info The
linker was unable to find your .pdb file. Copy it into the directory
that contains object/library.
To find the name of the .pdb file associated with the object file:
Extract an object file from the library with lib
/extract:objectname.obj xyz.lib.
Check the path to the .pdb file with dumpbin /section:.debug$T
/rawdata objectname.obj.
You could also compile with /Z7, so the pdb doesn't need to be used,
or remove the /DEBUG linker option if you do not have .pdb files for
the objects you are linking.
I was already using the right lib for debug configuration but was not only linking to GLFW.lib but also to GLFWDLL.lib. You can either compile GLFW into you executeable by using GLFW.lib or use a DLL by linking to GLFWDLL.lib. I accidentally did both.
Additional info at
4.2 Link with the right libraries
in the current GLFW 2.7 Release Notes.
Related
I am trying to build the boost.thread library for Visual Studio 9.0. I used bjam to build the lib-files:
bjam toolset=msvc-9.0 variant=release threading=multi link=shared
The compilation succeeded and I got plenty of .lib and .dll files under boost/stage/lib.
Then I added include path and the above lib path to Visual Studio 9.0.
But when I try to compile some program, I always get the following error:
libboost_thread-vc90-mt-s-1_49.lib cannot be opened.
The lib file created by the build has slightly another name:
boost_thread-vc90-mt-1_49.lib
I tried to rename my file to match the expected name, but Visual Studio still cannot find the file.
It seems that the filename beeing seaarched depends on the project option "C/C++ / Code generation / runtime library". I need the option "Multithreaded /MT".
What am I doing wrong?
Thank you in advance.
You're trying to link statically with CRT, but dynamically - with Boost. This is not a good idea, but if you insist, you should define BOOST_ALL_DYN_LINK macro.
Better option would be to select /MD in your project options, or to set "link=static" when building boost.
I have a CMake module to locate FreeGLUT:
FIND_PATH(FREEGLUT_INCLUDE_DIR NAMES GL/freeglut.h)
FIND_LIBRARY(FREEGLUT_LIBRARY NAMES freeglut freeglut_static)
SET(FREEGLUT_LIBRARIES ${FREEGLUT_LIBRARY})
SET(FREEGLUT_INCLUDE_DIRS ${FREEGLUT_INCLUDE_DIR})
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(FreeGLUT DEFAULT_MSG FREEGLUT_LIBRARY FREEGLUT_INCLUDE_DIR)
MARK_AS_ADVANCED(FREEGLUT_INCLUDE_DIR FREEGLUT_LIBRARY)
It works fine and locates freeglut_static.lib when I generate NMake Makefiles on Windows. I'm attempting to statically link FreeGLUT into my DLL:
FIND_PACKAGE(FreeGLUT REQUIRED)
ADD_LIBRARY(vti SHARED ${VTI_SOURCES})
ADD_DEFINITIONS("-DBUILD_VTI=1 -DFREEGLUT_STATIC=1")
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/include ${FREEGLUT_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(vti ${FREEGLUT_LIBRARIES})
My source code builds correctly, but when it gets to the linking stage, VC++ fails with:
LINK : fatal error LNK1104: cannot open file 'freeglut.lib'
Which is strange since freeglut.lib isn't mentioned anywhere that I can see in the generated NMake makefiles. It should be trying to link with freeglut_static.lib, which CMake locates and sets in FREEGLUT_LIBRARIES.
What might be causing this?
This is caused with pragma directives in FreeGLUT code (see freeglut_std.h). Using FREEGLUT_STATIC should really fix that for you, but I think you should pass it to CMake without quotes: ADD_DEFINITIONS(-DBUILD_VTI -DFREEGLUT_STATIC)
Am trying to compile a 64bit version of PyISAPIe using VS2010. Am not used to C/C++ programming but managed to configure some settings for VS2010. Everything went well until it got to the linking stage where it gave the above mentioned error. I checked all the Library path settings and they looked fine. Below is my command line for building the DLL:
/OUT:"x64\Release\PyISAPIe.dll" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\pyisapie\Python\x64\Python27\libs" /LIBPATH:"C:\pyisapie\Python\x64\Python26\libs" /LIBPATH:"C:\pyisapie\Python\x64\Python25\libs" /DLL "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /NODEFAULTLIB:"libc libcmt msvcrt" /DEF:"PyISAPIe.def" /MANIFEST /ManifestFile:"x64\Release\PyISAPIe.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /PDB:"C:\pyisapie\x64\Release\PyISAPIe.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /PGD:"C:\pyisapie\x64\Release\PyISAPIe.pgd" /LTCG /TLBID:1 /DYNAMICBASE:NO /IMPLIB:"x64\Release\PyISAPIe.lib" /MACHINE:X64 /ERRORREPORT:QUEUE
The path C:\pyisapie\Python\x64\Python27\libs exists and containes python27.lib.
Can anyone help me out. Thanks in advance
I just compared your linker command line to mine (I'm the project author) and it's exactly the same as far as flags go, so you might want to look into other reasons why the file can't be opened. Is it an x64 lib for sure? Do you have access?
You might try reinstalling the newest 2.7 x64 release into a different location and add that folder instead.
I had the same issue due to not setting the LIBPATH correctly. This may not be the cause of your error message, but it was the cause of mine.
To resolve it in Visual Studio right click on the PyISAPIe project and select:
Properties > Configuration Properties > Linker > General
Then make sure that the path C:\pyisapie\Python\x64\Python27\libs (or the relative path) is listed in the "Additional Library Directories"
When linking my dll in release build I get -
1>LINK : warning LNK4098: defaultlib
'mfc80d.lib' conflicts with use of
other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib
'mfcs80d.lib' conflicts with use of
other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib
'msvcrtd.lib' conflicts with use of
other libs; use /NODEFAULTLIB:library
adding /VERBOSE, I see the following (snippet):
...
1> Searching D:\Microsoft Visual
Studio 8\VC\atlmfc\lib\mfc80d.lib:
1>
Found "public: virtual __thiscall
AFX_MODULE_STATE::~AFX_MODULE_STATE(void)"
(??1AFX_MODULE_STATE##UAE#XZ) 1>
Referenced in mfcs80.lib(dllmodul.obj)
1> Loaded
mfc80d.lib(MFC80D.DLL)
1> Found "long stdcall
AfxWndProc(struct HWND__ *,unsigned
int,unsigned int,long)"
(?AfxWndProc##YGJPAUHWND__##IIJ#Z)
1>
Referenced in mfcs80.lib(dllmodul.obj)
1> Loaded
mfc80d.lib(MFC80D.DLL)
...
If I'm interpreting this correctly, it means the linker somehow resolves calls from the (optimized) library mfcs80, as calls into the (non-optimized) library mfc80D. How can this be??
When I add /NODEFAULTLIB:mfc80d.lib the warnings are gone, but I'm not quiet with it yet. As an aside, the module does indeed suffer from sporadic inexplicable crashes on incremental links, that are solved only by a re-build. I'm using VS2005.
[Edit:] Changed the title to include DEFAULTLIB, hopefully better focusing the subject. I do see an explicit line saying
processed /DEFAULTLIB:mfc80d.lib
in the /VERBOSE output, among many other (non-debug) default libs. Where does it come from? how can I fix this?
Thanks!
You should check the run-time library settings for your projects, sounds like you have a mismatch. In your project settings under C/C++ > Code Generation > Runtime Library, you have the choices:
Multi-Threaded
Multi-Threaded Debug
Multi-Threaded DLL
Multi-Threaded Debug DLL
It sounds like some of the projects in your solution may be using a Debug version while others use the Non-Debug version. Or alternatively, some projects may be using the Debug version while others are using the Debug DLL version. For a given solution configuration, you want all of the projects to use the same setting.
The issue was resolved much later - I post it up here in case it helps somebody someday.
It turned out to be a wrong precompiled header path: release configuration pointed to the default debug PCH path. So on transition from debug to release, a build would drag in all the debug PCH contents - apparently including some debug versions of MFC #pragma (comment "lib..") (included in afx headers). A clean build would rebuild the PCH correctly, but again into the debug folder - thereby causing identical problems on transition back to debug build.
It means that one of the dependent dlls is compiled with a different run-time library.
Project -> Properties -> C/C++ -> Code Generaion -> Runtime Library
Go over all the libraries and see that they are compiled in the same way.
More about this error in this link:
warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs
VS C++ 2008
I am just working through a DirectX tutorial.
In the source code had this line:
#pragma comment (lib, "d3d9.lib")
When I compiled everything linked ok.
However, I commented out this line and tried to include the header and library myself under properties, like this:
C/C++ - General
Additional include directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Include"
Linker - General
Additional library directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x64"
Linker - Input: d3d9.lib
However, I got this linker error:
1>main.obj : error LNK2019: unresolved external symbol _Direct3DCreate9#4 referenced in function _initD3D
However, when I just use the pragma I didn't get any linker errors. Only when I try and include them with the properties as above.
What is the real difference in using pragma and including the header/libraries using the properites?
Many thanks,
at first, #pragma comment(lib) is just linker configuration
at second, the SDK should be in path, so dont set additional library directories (you may override it with wrong version), just add d3d9.lib to linker's input.
As far as I know, there is no difference. pragma lib simply says to the linker to look for a specific library by name.
Also, since the path is not specified in the pragma, the linker relies on the current lib paths for your project. Try not add any path to your linker options (by default DX SDK adds paths to any visual studio installed, directly modifying the global visual studio paths. See Tools/Options/Projects and Solutions/VC++ Directories/Show Directories for Library files)
Some things to check:
you are indeed building for x64
your path is really pointing to the DX SDK (it is installed to Program Files(x86) if you are on x64)
verify if there are not other linker warnings