I got some compiled C++ libraries (.lib, not compiled by myself) which I link in my own C++ project. I also got the source code.
Is it possible while debugging to step into functions from those libraries using the source code? How can I tell the Visual Studio debugger to use those source code files?
I guess that .lib files would need some kind of debugging information - can I find out if they got those?
Microsoft compilers store debugging information in separate .pdb files. When VS loads a library (say myLib ) used by an executable ( either by attaching to a running instance, or by starting it directly under debugger), it also searches for myLib.pdb. If it finds it, when you try to step in such a function, it will first ask you the location of the source corresponding to it. If it is correctly provided, you will be able to debug it.
Without .pdb files, I do not know any way to debug the external library at source code level.
Also, if there are no .pdb files, but you do have the source code for the external library, would it be possible for you to re-build it with debugging symbols (.pdb files ) ?
Related
Situation
I learned a lot over the last year, but this is something I just could not wrap my head around. Project is C++. CMake 1.15.2. Visual Studio 2015.
I converted a whole Solution *.sln file with cmake-converter and wrote FindXXX.cmake Modules for all external *.libs defined in the *.vcxproj files.
Everytime I encountered an error: unresolved external I added the corresponding Target Sometarget::somecomponent to the target_link_libraries(ConsumingTarget ... ) call.
Now I have a build that works and produces no errors. Some executables say something along the lines of:
"Execution of code cannot be continued because somecomponent.dll is not found..."
I have
An original .sln file that produces executables only requiring .lib files
A CMake generated .sln file that produces executables requiring .dll files
Working FindXXX.cmake files which add_library(XXX::yyy UNKNOWN IMPORTED)
They find the headers and the .lib files (.dll files are not existing/intended/needed in the original VS .sln)
They create the corresponding Targets for all .lib files
Consuming Targets which target_link_libraries(ConsumingTarget PRIVATE XXX::yyy)
"A working build"
An error "before starting the main function".
What I have tried
I have tried defining an OBJECT Library and adding this to the sources of ConsumingTarget and removing Sometarget::somecomponent from the target_link_libraries call. CMake Doc on Object Libraries
I have tried reading and understanding the difference between module and library. Even the CMake documentation on imported Libraries couldn't help me understand my problem.
I have tried reading and understanding the difference between linking a static and shared library.
My Assumptions
Adding the imported library is done wrong by me.
Reason: DependenciesGui.exe shows different dependencies for the cmake-generated-executable and the original-sln-executable but the linker calls (shown in VisualStudio 2015) seem to be the same.
Whole Program Optimization in the CMake File does not work the same way it does in the original .sln file although the Flags are activated at all levels described in this answer.
Reason: compiling with the original file I noticed warning C4505: 'foobar': unreferenced local function has been removed - I don't seem to get those warnings with the cmake-generated build.
subassumption: Functions which won't be called are optimized away, thus removing the necessity for the .dll file.
I expect/hope for
ConsumingTarget.exe to run without asking for somecomponent.dll
another explanation on imported targets and how to link libraries where .dlls should not be necessary.
an explanation on how to analyze/compare the two binaries regarding their symbols(?) and map the seen information to CMake commands. (I am using DependenciesGui.exe to look for dependencies in the .exe file)
Possible reason for failure
One executable had no /DELAYLOAD... directive after conversion with cmake-converter. Opened Issue. Question Title still holds.
Edits:
1: Added possible reason for failure
I have some confusion about static and dynamic linked libraries and .lib and .dll files.
I have a project with two libraries, one I built myself and one is from an open source library.
The one I built myself is a separate project in the same solution (Visual Studio 2015, C++), and I don't need to copy over the .lib files or create a DLL for the executable to build and run
For the other open source library, I do need to copy over the .lib file and the DLL into the executable folder. However, I thought it would be possible to statically link a .lib file and not have to copy over the DLL.
Does this mean I need to compile the Open Source library differently? Like change the define __declspec(dllexport) to __declspec(dllimport) ? Or change /mD to /mT in compiler options?
I tried both of these, but it's still saying that it can't start without the .dll
Or can I get away with changing a setting in the executable project to link this library statically? If so, what are these settings?
EDIT: I know this is a standard question that can be looked up on google, but I haven't been able to find an exact answer for a while. Mainly, I'm confused about what settings need to be changed, and which project they need to be changed in. (The library or the executable).
I'm under assumption that static linking means the library is built into the executable, and dynamic linking means the library needs to be in a separate file, if this is incorrect, please let me know. Otherwise, I need to know how to build the library into the executable file.
And I can go ahead and change the build options in the open source library, and I tried this already.
Thanks,
-D
In Windows, dll files (dynamically linked libraries) need to be in the same directory as the application or on the search path. lib files (static libraries) need to be statically linked during linking (the last step of building the application). It's common in Windows so have a library come with both a dll and lib file. In this case, the lib file is an import library containing the information needed to easily link to the dll.
Place the dll file where your application will be built and statically link with the lib file. Go to 'Project->Properties->Link->Input->Additional Dependencies' and 'Project->Properties->Link->General->Additional Library Directories' to specify the static libraries you want to link.
Edit: It seems I misunderstood the question. The question is how to recompile a dynamic library as a static library. You need the source code of the library you are using along with it's Visual Studio Project file. Open the library and in `Project->Properties->General->Configuration Type' change it from Dynamic Library to Static Library.
Beware that Dynamic Library uses the Linker group of properties while the Static Library uses the Librarian group of properties. Changing between these types may cause the project to drop essential linker flags options. Since every library is different, I can't predict what you will have to do work around this. Make sure to backup the project file so you can see the original options and flags.
I had to change the setting for "Static Library" for All Configurations, not just Debug, although it was building in Debug. Not sure what may have caused this. Possibly because the debug and release builds for the library were set to the same folder, it may have been overwriting the debug builds with release builds when building
I thought this should be straightforward but I am running into a bunch of linker errors like so:
Error 1 error LNK1104: cannot open file '...\Debug\Utils.lib' ...\LINK
where Utils is one of the C++ projects I want to keep as DLL.
If I change Configuration Properties->Configuration Type to Static Library(.lib) everything compiles and runs fine, but if I use .dll then its not working.
The whole solution is native C++ with the main project being a win32 console application.
Perhaps your library (Utils.lib) is not assembled as DLL and changes in console application project (that uses library) will not help.
Read carefully MSDN to see features of DLL's creation and usage.
It you try to link a .lib against another .lib, it doesn't really link. Instead, this instructs the final link to use both libraries.
For a DLL, this can't work, as the runtime linker cannot link the original .LIB. That means the link has to happen when the DLL is compiled.
As a result, a DLL project needs to have the .LIB directories set right.
I am trying to find a good way to determine what module at link time is causing a certain library to get processed as a "/DEFAULTLIB" as seen in the verbose linker output from Visual Studio.
Here is my situation, I have several static library pre-requisites and each has a release and a debug version (BlahD.lib and Blah.lib). For some reason at link time all of the *D.lib's are processed as default libraries even though I am building a release with the non-debug libs specified as "Additional Dependencies". If I never build the debug versions of the static libraries those *D files wouldn't exist and there would be a linker error (can't open file).
I can get my project to build successfully by specifying /NODEFAULTLIB for all of these offending .lib files. All the release libraries link up and everyone is happy. But I want to understand what is going on here. What is causing these *D.lib files to be processed by the linker? Is my only hope to write some kind of script that dumpbins everything in this massive project and its dependant projects (microsoft support)? Even then I don't understand what to look for in the dumpbin output, does this apply to the .lib files as well the .obj files?
I had a similar problem. I was only able to solve it by analyzing the *.obj files as you suggested. To do it, I ran the following command via the Visual Studio command prompt (in the temp folder of the project, where *.obj files are generated):
for /R %1 in (*.obj) do #dumpbin /directives /section:.drectve "%1" > "%1".directives.txt
Then I used Notepad++ to search for the name of the offending library in all of these *.directives.txt files. This revealed which project was referencing the wrong lib.
Note: you may want to modify this to include any 3rd-party *.lib files your project may use, and not just *.obj files. "/DEFAULTLIB" directives may also come from them.
Note: you may need to use *.o instead of *.obj
Look for #pragma comment(lib) in the source. See if it perhaps is dependent on a #define - This is a common way for a SDK to ensure that the right libs are linked, and you may need to define THESDK_DEBUG or THESDK_RELEASE for the logic to work out.
Additional information:
I discovered in Visual Studio 2008 that even commenting out the statement from the *.idl file does not work, as in:
//cpp_quote("#pragma comment( lib, \"MYLIB.lib\")")
The compiler still adds MYLIB.lib as a DEFAULTLIB, and it winds up in the *.obj file. Make sure you remove the line completely from the code!
Link with the /verbose option and search the output for the name of the library in question. This will tell you which object file dragged the library into the link.
I'm trying to use TinyXml++ in my project, and I have tested it successfully in a small program before. I recently decided to use it to read a configuration file in my current project and though the code compiled, I got a ton of linker errors (unresolved external symbols mostly). I read in some forum thread, describing a similar problem, that I had to use the same runtime library as TinyXml++ was compiled with. I opened the accompanying Visual C++ 2008 project and saw it was using Multi-threaded Debug (/MTd).
I have now tested all runtime libraries with and without #define TINYXML_USE_TICPP before I include "ticpp.h". I've gotten from 9 to 80 linker errors (which I why I initially didn't want to post them all, but I will if you want to see them).
I have copied the static library ticppd.lib (found in the download folder) to my project's directory and linked it under Linker->Input->Addtional Dependencies. I have included a directory path to the TinyXml++ source under C/C++->General->Addtional Include Directories. What am I doing wrong? :(
TinyXML is a library with the full source code available; you should not need to include a .lib. You could separate TinyXML into a separate project and mark your project as depending on it, which will allow you to compile both projects with consistent settings for threading and debugging, but the easiest way to get it working should be to just add the TinyXML .cpp and .h files (just not the test one) to your project and compile.