I implemented the SFML library nightly build to my Visual Studio 2013, because the original one is not compatibile with this VS version. I done everything what is needed (added directory to include folder in both Debug and Release, added directory to .dll files), but it can't find the files in program. What else should be done to make this library work? Or should i consider changing Visual Studio to 2010?
You haven't given really to much information so I am just really guessing as to what the problem is.
added directory to .dll files
But that sounds like your problem right there. You don't add the directory that the .dll files are in to your project. The only directories you need to add to the project are the include directory and the library directory.
But anyways I am assuming you are using dynamic linking since otherwise you wouldn't be dealing with .dlls. Now different IDE's require that you place the .dlls in different spots but since you are dealing with VS2013 you need to copy whatever .dlls that you are using into the same folder where your program's compiled executable is (The .exe file).
Another option is to link statically instead of dynamically which I generally prefer to do on small projects but it is really up to the developer which he prefers.
When you link statically you don't need to include any .dlls. What you will need to do is recompile SFML's sources and make sure to build the library so it produces the static library files (They should be named something like sfml-graphics-s-d.lib for debug and sfml-graphics-s-d.lib for release).
Add that library directory which contains the static library files to your project and then link to them .lib files in VS's input window (Remember that -d is for the debug build).
Next you will need to add SFML_STATIC to your preprocessor options on both the release and debug build.
After that you are good to go and don't need to include the .dll files with your project. And again whether you choose to link dynamically or statically is really up to you and the project you are working on but for small projects I would suggest linking statically.
I have a project whose output is a library (.lib). The project depends on a third party library (also a .lib). In order to avoid projects built on top of my library having to worry about this third party dependency, I have used the librarian to include it in mine (Project Properties > Librarian > General > Additional Dependencies).
However, when I build a separate executable project which links to my library, I get a bunch of warnings along the lines of:
MyProject.lib(someThirdPartyObjectFile.obj) : warning LNK4099: PDB 'vc110.pdb' was not found with 'MyProject.lib(someThirdPartyObjectFile.obj)' or at '\vc110.pdb'; linking object as if no debug info
This means (I assume) that I will be able to debug any code belonging to my library, but not to the third party library.
How can I instruct Visual Studio to also include the contents of the third party library's PDB in mine?
The static library has probably been moved, so the compiler can't find the symbols from it. You have several options:
change debugging format to /Z7, which embeds the debug info in the code (whereas /Zi and /ZI put it in a separate file).
change the output configuration of the pdb file (for VS2005 it was Settings > C++ > Output Files > Program Database File Name, probably similar in VS2010).
You can find more information here and here.
Go to Property Pages (Alt+F7)
Linker, All options, Generate Debug Info set into No Position
trying to profile with VSPerfCmd (VS2010 profiler), and also with Intel VTune Amplifier XE 2013: some results are available, for VsPerfCmd in .vsp file. However, profier is not picking up pdb. no code is available for some parts of the application.
Did this happened to you already, and do you know if some compiler options should be turned on so as to get complete profile?
in which directory does profiler go to find .pdb info ?
thanks
The profilers and debuggers on Windows by default look up the PDB files by the path written in the executable. So the first thing to do is to open the executable in some hex editor and search for ".pdb" string and check whether file mentioned there exists on disk. If that is not the case, check that you specify /Zi or /ZI option to the compiler and /debug option to the linker.
If symbolic names are missing for SOME parts of the application, check whether those parts are separate dynamic or static libraries and whether you generate debug information for those. In case of static libraries it's easy to get the debug information lost along the linking way since by default /Zi flag embeds the debug information into the vc*.pdb file (e.g. vc90.pdb for VS 2008) and that file is usually not exported into SDK by build systems. For static libraries I personally find the most instrumental to use /Z7 option for debug information since that embeds it into the object files themselves and then to the *.lib file and then it propagates to the final *.exe / *.dll binary's PDB file.
I have downloaded the latest version of SFML (a library) which includes source files, dlls, headers, and .lib files.
I have no problem using the library and it's linked dynamically.
I'd like to be able to step through the library code in the debugger (I used to be able to which earlier version), but now I can only see the assembly.
What is the usual way to generate pdb files to so?
thanks
Generally Visual Studio 2010 should automatically generate .pdb files for you (if you build in debug mode). Take a look in your Debug output folder. You can see where and what .pdb is being generated from your project settings;
Sterren
In VS2010 there is an option to generate debug info for exes/dlls under linker but no such option under librarian for libs. Is the debug info embedded in the static library?
There is an option in the C/C++ properties for Program Database File Name for libs, exes, and dlls. By default it goes into my intermediate directory and is named the project name for libs, but is named vc$(PlatformToolsetVersion).pdb for exes/dlls. What's the pdb from this option and how does it differ from the pdb in the linker option?
If I am supplying a library with libs and headers how do I supply debug symbols to a user of my library?
If you use /ZI or /Zi (C/C++ -> General -> Debug Information Format), then the vc$(PlatformToolsetVersion).pdb is created, which contains the debug info for all of the .obj files created. If alternately you use /Z7, the debug info will be embedded into the .obj file, and then embedded into the .lib. This is probably the easiest way to distribute the debug info for a static library.
I wouldn't advise distributing a static library, however, since it's generally tied to a specific version of the compiler.
Expanding upon previous answers, for those who need the full how-to (VS 2013 minimum).
Note that this should address comments ^^above regarding VS2013 issues.
Method 1: The Program Database (.pdb) Way (/Zi or /ZI)
Static Lib Project: Generate a pdb with same name as your static lib:
Open Solution Explorer from the View menu.
Right click your static lib project, select Properties
Edit Configuration Properties->C/C++->General->Debug Information to /Zi or /ZI
Note that /ZI allows "Edit and Continue" editing during debugging
Edit Configuration Properties->C/C++->Output Files->Program Database File Name to $(OutDir)$(TargetName).pdb
Now compile it, and note where YourLib.lib and YourLib.pdb are.
Application Project: Link your executable with the static lib, and new PDB file:
Again, navigate to project properties, but this time, for your Application project
Again, edit Debug Information property as needed.
Edit Configuration Properties->Linker->General->Additional Library Directories, adding your own "libs" directory, or whatever directory you plan to keep/copy your YourLib.lib and YourLib.pdb files.
Edit Configuration Properties->Linker->Input->Additional Dependencies, adding YourLib.lib (no path in front)
Now copy both YourLib.lib and YourLib.pdb to the directory you specified above.
Method 2: The Embedded Symbols (no .pdb) Way (/Z7)
Static Lib Project: Generate a static lib with embedded debug symbols
As in Method 1, navigate to project properties
As in Method 1, modify your Debug Information, but this time to/Z7
As in Method 1, compile and note where YourLib.lib is generated.
Application Project: Link you executable with the static lib
As in Method 1, navigate to project properties
As in Method 1, modify your Debug Information property as needed
As in Method 1, edit Additional Library Directories
As in Method 1, edit Additional Dependencies
Now copy YourLib.lib to the directory specified in Additional Library Directories
Discussion:
Advantages of Z7? It's simpler, and the "Single-file" way of doing it. All the debug info is in the lib file.
Disadvantages of Z7? File size on-disk, link times, incompatible with "Minimal rebuild" (/Gm) feature, does not allow "Edit and Continue", older format (e.g. older paradigm)
Why don't I specify Debug Information Setting for Application Project? This post is concerned with how to get debug working in static lib code. The same "Method 1 vs Method 2" choice applies for the Application project as well.
I notice in VS2013 it is possible to set the program database file name in the C/C++ Output Files tab. Changing it from the default to something like $(OutDir)$(TargetName).pdb resolves the issue
Static libraries are implemented into the programs that use them.
If the program that uses them is using debug symbols, the compiled library code in that program will have symbols too.
PDB info from wikipedia:
When debug symbols are embedded in the binary itself, the file can
then grow significantly larger (sometimes by several megabytes). To
avoid this extra size, modern compilers and early mainframe debugging
systems output the symbolic information into a separate file; for
Microsoft compilers, this file is called a PDB file.
Weird behavior in VS2012. Building from scratch (or with /A option in nmake) will produce a .pdb file. Now delete the .lib and .pdb and rerun nmake (without /A of course, to run only link) and no .pdb file is output.