My project has a lot of static library (with sources).
Some base libraries can't be breakpointed because the source code is different from the original version.
I know I can workaround if I turn off "Require source files to exactly match the original version" option, but that warning makes me worry.
Is it Microsoft Visual Studio 2008 bug?
I heard it happen when checksum of source code is different with obj.
I have all sources of library and linked as static library,
I cleaned and rebuilt all, but warning never disappeared.
What a worse is, when I turn off "Require source files to exactly match the original version" option, watch windows can't show what member variable has with this error "FIX: CXX0033 Error in OMF Type from Forward Class Declaration"
http://support.microsoft.com/kb/131147/en-us?fr=1
I searched stack overflow and find several similar article (http://stackoverflow.com/questions/163133/breakpoint-not-hooked-up-when-debugging-in-vs-net-2005) but those couldn't help me.
Environment :
Windows 2003 server x64
Visual Studio 2008 sp1 Version 9.0.30729.1 SP
Thanks in advance.
Double check your symbols and sources search paths to ensure they include the right folders with the static library. Check that y7ou are linking the .lib and the .obj files from the right directory. Also, break in program under the debugger, and check where are the symbols for the library loaded from - they should be from the same folder the .obj and the .lib came from.
Related
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.
In Visual Studio 2003, if I link with a library that doesn't have its corresponding PDB file, I get a warning:
foo.lib(bar.obj) : warning LNK4099: PDB 'other.pdb' was not found; linking object as if no debug info
If the PDBs are in their original build location VS can find them, as well as if they're in the current build directory, but that seems to be it. Is there a way I can tell Visual Studio exactly where it should look for PDBs? I have a vague notion that a symbol server might work, but that seems like a lot of overhead; I'm just looking for something like link.exe /pdbpath c:\pdbs_are_right_here that adds a path to search, like /I adds an include path. Alternately, are there other paths it searches besides the current directory and the original absolute path the PDB was written to?
I believe the path to the corresponding pdb's is embedded in the libraries themselves, and you can change it into c:\pdbs_are_right_here at the build switches for your libraries (assuming they are indeed yours and not 3rd party).
For DLL's that means project properties\linker\debugging\generate program database file.
For static libraries the default name is uniform in VS2013 ('vc120.pdb'), but I think this changed in VS2015 and have no idea about VS2003. Anyway if you're working in VS2013\2012\2010 you'd have to explicitly override the name too.
I have VS Studio 2010 SP1 installed and there was a time when source stepping was working great. Something has changed and now when the pdb files are downloaded they are the version that has the source code stripped out.
What I can't figure out is how to get VS to download the pdb files that have the source code in them. I have the same setup on 2 different machines and 1 machine downloads the pdb's with source and the other one does not.
I have been fighting for hours trying to get it to download the correct pdb files. I can easily check if the files are correct because the file size is so much smaller when there is no source.
Machine that is downloading with source System.Web.pdb size is 10,860 KB.
Machine that is downloading without source System.Web.pdb size is 843 KB.
Your help in figuring out this issue is greatly appreciated.
Also, please not I have cleared the cache, setup and reset the symbol settings, etc. The files download and do load as symbols, just NO source.
C:\Windows\Microsoft.Net\assembly\GAC_32\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.pdb: Cannot find or open the PDB file.
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\System.Web.pdb: Cannot find or open the PDB file.
C:\SymbolCache\MicrosoftPublicSymbols\System.Web.pdb\46C6DCE3C79A4E65A2B1CEF3033C95931\System.Web.pdb: Symbols loaded.
This behavior is often caused by Microsoft publishing updates to the .NET Framework.
When you use Visual Studio 2010's built-in default symbol configuration (by having "Enable .NET Framework source stepping" checked), you effectively query these two servers:
http://referencesource.microsoft.com/symbols
http://msdl.microsoft.com/download/symbols
No. 1 contains source-enabled symbols for the .NET Framework (parts of it at least) and no. 2 contains source-stripped symbols for all Windows.
The problem is that no. 1 is updated not as quickly as no. 2, so when an update arrives through Windows Update, you start getting symbols from no. 2, until someone at Microsoft updates no. 1. It's a pain, but that's how it is.
You can sort-of work around it by deselecting "Enable .NET Framework source stepping" and configuring those paths manually - then you can just disable (or not add at all) no. 2, and at least be informed, that there are no source-enabled symbols available yet.
Or you can disable Windows Update...
Today I fired up Visual Studio 2010 (Visual C++) and started working on a project. The solution contains two projects. One is a static library I am writing, the other is a test application containing unit tests for the library.
Without changing anything from yesterday, the executable no longer links:
LINK : fatal error LNK1104: cannot open file 'mylib.lib'
The static library compiles and links fine. I have not changed the project settings in around a week, and it was linking just fine yesterday.
If I go into the executable project's settings and add a library directory for $(SolutionDir)\debug, I instead get the following link error:
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
I am not sure what the problem is. I have tried cleaning, rebuilding, and even rebooting my machine. Google turned up some bugs in ancient Visual C++ versions (but I'm using 2010), as well as the possibility that the program is already running. However, it is not running, and a reboot confirms this.
What would cause the linker not to find core libraries such as kernel32.lib, or for that matter, the output directory for my solution?
This is old-fashioned C++, a cross-platform library, not that managed stuff Microsoft added.
I had to check "Inherit from parent or project defaults" in the "Library Directories" dialog. Once I did that, the linker could find all the necessary libraries. I still had to include $(SolutionDir)\debug though.
Include the microsoft SDK directory in project->properties->linker->general->additional library directories.
on my computer it is
D:\Program Files\Microsoft SDKs\Windows\v7.1\Lib
I fixed this problem by disabling "Enable .NET Framework source stepping" (see: "Menu bar / Tools / Options / Debugging / General / Enable .NET Framework source stepping"). Apparently this is a bug in Visual Studio.
I am building a project in Visual Studio 2005 that require some libraries that were built in Visual Studio 2003. I'm getting linker errors like
msvcprt.lib(MSVCP80.dll) : error LNK2005: class std::basic_string[...]already defined in libdiguy.lib(bdiNavMesh.obj)
I believe that my program and the libraries are both compiled dynamically instead of statically. I've also tried changing the /MD and /MDd options because that seemed to be the solution to similar errors. My best guess at the moment is that it needs to link against MSVCP70.dll instead of MSVCP80.dll to resolve these errors. Is there a way I can compile against the older dll to see if that will fix it?
Thank you!
As far as I know you have two options: either get a VS2005 version of the libraries, or keep using the VS2003 headers and libraries. The first is in my opinion the better option because you will not benefit from fixes MS made in headers and libs. But it may be difficult or even impossible. The latter can be done by changing the VS2005 directories to the corresponding VS2003 ones. I think that you also have to ignore all default libraries and explicitly specify the ones from VS2003.
Hope this helps.
Cheers,
Sebastiaan