I am using Visual Studio 2008 with CPPUNIT. I already compiled CPPUNIT and added the CPPUNIT path to Include and Library path. Currently, I can compile my program with CPPUNIT library.
However, the linker generates the following warning:
Warning 2 warning LNK4099: PDB 'vc90.pdb' was not found with
'C:\Program Files\cppunit\cppunit-1.12.1\lib\cppunitd.lib' or at
'c:\Users\hide1713\Desktop\3d_tank\cpp_pj\bin\vc90.pdb'; linking
object as if no debug info cppunitd.lib GameUnitTest
There's a cppunitd_dll.pdb file along with cppunitd.lib. How do I tell the linker where to find the CPPUNIT debug database?
Thanks all.
In your CppUnit project, be sure you have your compiler emitting a program database file that's compatible with your main project. In the CppUnit project properties window, under the Config properties / C++ / General tree, you'll see the Debug Information Format box. Select "Program Database /Zi" or whatever value exactly matches the same setting on your main project. You'll then have to recompile them both, of course.
Related
I am trying to make assimp work with Visual Studio 2013, but I always get this error:
Error 1 LNK1107: invalid or corrupt file: cannot read at 0x2F0
I followed all the steps here -> Assimp model loading library install/linking troubles
Built assimp from source using cmake, Visual Studio 12 2013 and put the includes and generated dll file in the solution folder. Added the paths in visual studio VC++ Directories (Include, library), C++ (Additional include dirs), Linker (Additional Library dirs, Additional Dependencies).
Am I missing something?
In addition, can someone suggest some other tools to read obj files and load vertex/index/texture buffers directly from the file?
You need to link against the assimp.lib, not against the assimp.dll. The lib is used to say your aplication that it has to load the dll when starting your application.
How to compile a VB6 program with extra debugging information (PDB file / symbols)?
If I just choose "Make DLL" from the File menu, no PDB file is created.
From https://support.smartbear.com/viewarticle/2357/
Compiling Microsoft Visual Basic 6.0 Applications With Debug Information
This topic explains how to compile Microsoft Visual Basic 6.0
applications with debug information...
Visual Basic may include debug information in the executable file, or
add debug info to an external PDB file. ...if you compile a release
version of your product, it is recommended to generate debug
information as an external file. This will decrease the overall size
of your executable.
To specify the way in which debug information will be generated, use
the Link environment variable. If this variable is not defined, Visual
Basic will generate an external PDB file. Else, the compiler will
include the debug information in the executable. For more information
on this, see Visual Basic documentation.
To compile your Visual Basic application ... follow these steps:
If you compile a release version of your product, make certain that the Link environment variable is not defined. If this
environment variable exists, Visual Basic will embed debug information
in the executable and thus the overall size of your application will
increase.
Open your project in Microsoft Visual Basic.
Select Project | Project Properties from Visual Basic’s main menu. This will open the Project Properties dialog.
Move to the Compile tabbed page and select the Create Symbolic Debug Info check box:
Press OK to close the dialog.
Recompile your application.
There is no need to ship the generated PDB files along with your
application.
I did the following experiment: I created a statically linked C++ library solution MyLibrary (I took the code from the MSDN example: https://msdn.microsoft.com/en-us/library/ms235627.aspx.) and built it. Then I created another C++ solution MyConsoleApp, using the console application template in Visual Studio (2017). I copied the MyLibrary.lib file to the root of MyConsoleApp project and added MyLibrary.lib to Linker -> Input -> Additional Dependencies (also had to copy over the headers too of course). What I didn't do was to copy over the MyLibrary.pdb file.
I would've expected to get a linker warning about the missing .pdb file but this was not the case. Then I moved only MyConsoleApp to another machine and tried to build it again, this time getting a missing .pdb linker warning. It seems that Visual Studio is storing the .pdb files when building a solution somewhere on the machine and is able to use those .pdb files when linking other solutions on the same machine.
I would like to be able to disable this behaviour or to be able to remove the cached .pdbs so that I could be sure that when sharing work with other developers they won't get warnings that I'm not getting on my own machine.
Visual Studio doesn't cache the .pdb file. What happens here is that the absolute path to the original .pdb file is stored in the build outputs (.exe, .dll or .obj files) and Visual Studio is able to took it up based on that.
Check this answer for a way to prevent that: Remove PDB references from released file.
I have a project in visual c++ where I am referring some external DLL.
I have already included the lib directory in linker section and mention it in the input section of the linker and also included the same in c/c++ General Additional Include Directories section.
Thus the project compiles successfully but whenever I try to run it; it fails with an error "Application was unable to start correctly" but if I see the output section it seems everything is loaded correctly but against that particular Dll it says that "Cannot find or open the PDB file".
How to fix this error so that I can run my program. It is an MFC program running in Visual Studio 2010.
when I run the program through the Dependency Walker, most of the API-MS-WIN-CORE-HEAP, FILE, and EXT-MS-WIN-SESSION USERMGR -l1-1-0.dll many similar to this are unavailable. I even tried to repair the visual studio it didn't work. Is there any idea how to go about it
0x0000007b sounds familiar to me.
Most likely that is due to 32/64 bit library mixture you are linking with.
Either you are building for x64 and linking with a win32 external library or vice versa.
In your Visual Studio project settings separately configure platform architectures you are compiling for and then you can choose the profile which you are actually compiling for.
I've included a NuGet package (Edge.js) that I would like to debug by stepping into the source code. When I "step in" it "steps over". I'm guessing this is because there are no symbol file to step in to. Possibly the EdgeJS package was published without sources and this could be the reason. However I don't know how to verify if a NuGet package contains the pdb symbols.
It might also be that I failed configuration of Visual Studio but because I don't know if the NuGet package contains symbols I don't know which way to look.
Thanks for any help
Nuget supports creating packages that contain PDB and source files with the nuget pack -Symbols command. Usually, these packages are uploaded to symbolsource.org for open source projects. Visual Studio can be configured to use symbolsource.org during debugging, see this guide.
However, not every open source project uploads symbol packages to symbolsource.org, so you have to check whether Edge.js does (I don't know that library).
If Edge.js does not provide symbol packages, your options are as follows:
Download the edge.js sources and build locally with debug symbols. Copy the DLL and the PDB to the output folder of your application and start debugging.
Use a decompiler. You don't get as much information as with the debug symbols and source files, but it may suffice for your case. The decompiler that ships with Resharper (commercial tool) is pretty useful for debugging DLLs in this manner.
You can't "step-into" anything if you don't have the source code. Debug symbols won't help in this case.
You can step-into the decompiled code only by using third-party tools like RedGate's Reflector or Telerik's JustCode that decompile the IL on the fly and generate C# code for viewing purposes. These tools don't need the debug symbols to work, although they can use them to make the decompiled code more presentable.