I am developing a project in VC++2008. The project uses the OpenCV library (but I guess this applies to any other library). I am working with the Debug configuration, the linker properties include the debug versions of the library .lib's as additional dependencies. In VC++ Directories under Tools|Options i set up the include directory, the .lib directory, the source directories for the library as well. I get an error while calling one of the functions from the library and I'd like to see exactly what that function is doing. The line that produces the error is:
double error = cvStereoCalibrate(&calObjPointsM, &img1PointsM, &img2PointsM,
&pointCountsM,
&cam1M, &dist1M, &cam2M, &dist2M, imgSize, &rotM, &transM, NULL, NULL,
cvTermCriteria(CV_TERMCRIT_ITER + CV_TERMCRIT_EPS, 100, 1e-5));
I set up a breakpoint at this line to see how the cvStereoCalibrate() function fails. Unfortunately the debugger won't show the source code for this function when I hit "Step into". It skips immediately to the cvTermCriteria() (which is a simple inline, macro-kinda function) and show its contents. Is there anything else I need to do to be able to enter the external library functions in the debugger?
EDIT: I think the cvTermCriteria() function shows in the debugger, because it's defined in a header file, therefore immediately accesible to the project.
EDIT2: The .pdb files were missing for the library files, now I recompiled the OpenCV library in Visual C++ in Debug configuration, the .pdb files exist but are still somehow invisible to the debugger:
Loaded 'C:\Users\DarekSz\Documents\Visual Studio 2008\Projects\libcci\Debug\ccisample.exe', Symbols loaded.
'ccisample.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll'
'ccisample.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll'
'ccisample.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll'
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cv210d.dll'
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cxcore210d.dll'
The symbols aren't loaded apparently for the opencv dlls. Still, the .pdb files exist in the \bin directory.
To sum up all the activity in the comments: the key to the solution was to rebuild the library in VC++ to obtain the .pdb (Program Debug Database) files for debugging, the precompiled "-d" suffix libraries weren't enough. Still, the import libs for the library dlls made the program load precompiled dlls from the OpenCV package tree, not the ones from my build with the .pdb information (the paths were similar so I didn't notice at first). The path to the .pdb files was provided in Tools|Options, but these files weren't loaded because of module version mismatch (obviously). Once I copied the correct dlls and their respective .pdb files to the application directory, the debugger started working inside the library functions.
Confirm: are you actually compiling the OpenCV library from source, or are you just linking against it?
A couple of possibilities come to mind:
It sounds like the debug info for the OpenCV library is not available (the PDB files). You may have to extend PATH to reference the directory containing these files. It seems to me that there is a way of doing this from VC++ but I'm a few years out from using the tool...
Is cvStererCalibrate also a "macro function"? If so, find out what real function it refers to and set the breakpoint in the library.
Finally, although you have already said so, it never hurts to go back and confirm that full debugging has been activated for everything in the project, including external libraries.
I don't know if this helps, but its a good place to start.
i got the same problems, which is:
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cv210d.dll'
'ccisample.exe': Loaded 'C:\OpenCV2.1\bin\cxcore210d.dll'
I solved it by:
Linker -> Input -> Additional Dependencies add: 'cv210.lib; cxcore210.lib; highgui210.lib;'
instead of adding : 'cv210d.lib; cxcore210d.lib; highgui210d.lib;'
Related
I am trying to include a external library (.lib pointing to a .dll) in my project. I am building on windows using QT (it appears to be using msvc2010 as the compiler) and have: LIBS += <path>/<libraryName>.lib in my .pro file. I have the corresponding .dll file in the directory where the executable is output so it can be found. When the program is run I get the following from QT:
Starting (program name)...
The program has unexpectedly finished.
(program name) exited with code -1073741515
Searching around it seems this type of error can come from .dll files being different in some way than you expect, which seems to be at least partially the problem here. When I open my program with dependency walker I can see that my .dll file found and the functions in it look to be correct as far as I can tell. However in the parent import function pane the functions do not agree or look correct (I think why I am getting my error). These function definitions exactly match the functions from another external library that I am using.
To me this indicates that somehow the .lib file is incorrect, however I have used this pair of .lib/.dll files before in a different program (not built in QT) and they worked fine. Also I have tried removing the reference to the .lib file from my .pro file and the correct functions calls complain (the ones from this library defined in the .dll file that is found). The .lib file looks exactly how I would expect it too using Dumpbin.exe /EXPORTS to view its content.
Any thoughts on what dependency walker is trying to tell me or what I should be trying now would be awesome.
edit 2/8: I have constructed a minimal example. It stops with the same error however in dependency walker instead of showing the functions from another library it shows no expected functions.
Looking at the explanation given for your minimal example it would seem what is happening here is that there are no MinGW function calls for the library (they are all MSVC calls). The functions found in the libraries are listed correctly because they are, just not being linked form the other compiler. As for why different libraries functions are showing up, I would guess its a bug in dependency walker.
I am trying to build Quantlib using Boost Libraries.
I followed the instructions here: and also on the Quantlib website.
I downloaded and unzipped boost_1_57_0 into C:\program files
I then used the Visual Studio 2013 x64 Native prompt to go to the boost directory and ran
bootstrap.bat
and then
b2 --toolset=msvc --build-type=complete architecture=x86 address-model=64 stage
Then I opened Quantlib_vc12.sln in Visual Studio 2013.
Picked "Release" and "x64", opened "Quantlib" in Property Manager and set the VC++ Directories.
In the include directories I added C:\Programm Files\boost_1_57_0
In the Library Directories I added C:\Program Files\boost_1_57_0\stage\lib
Then I went to the Solution Explorer and right clicked and chose build.
I got one LNK1104 error.
LNK1104: cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
Please see attached screenshot:
I have no idea how to fix this and I would really appreciate some help. I had successfully installed this at work using an admin account but was not able to access Quantlib using my user account. I have since deleted and attempted installations atleast 15 times but it's not working. I am worried that all these attempts at installing may have messed something else up, like some registry (I have no idea how that works but I only know to be afraid). Please help! Thanks.
UPDATE: Still get the same error after adding BOOST_AUTO_LINK_NOMANGLE define to project.
UPDATE2: I am getting these messages on the screen while running b2 to build boost. Is this an error I need to fix?
This is exactly what I warned you about in another related question/answer. What's happening here is that the boost headers you are including in this quantlib are (through macros) detecting that you're using MSVC, detecting the version, then automatically linking the required DLL files to build quantlib using #pragma comment(lib....). So even though under Project Settings -> C/C++ -> Linker there are no external DLL's or Lib's specified, they're still being linked by these pragma statements.
So when these macros are detecting your compiler and so on, they're dynamically building a string name of what they think the required libraries would be named on your system. Remember when you built boost, you specified the -layout option. This the naming layout of your boost libraries. Well by default, that layout is something like this:
LIB_LIBRARY_NAME_COMPILER_VERSION_SingleOrMultiThreaded_BOOST_VERSION.LIB
Which in practice looks like this:
libboost_unit_test_framework-vc120-mt-1_57.lib
This is boost "mangling" the name of your library to be as descriptive as possible about how the libraries were build so that, just by glancing at the file name, you know. What we do with -layout=system is tell the boost build system NOT to mangle the names, but to name them according to what option we gave to "layout". Since we chose layout=system, boost is going to name our libraries like this:
LIB_LIBRARY_NAME.LIB
Which in practice will produce:
libboost_unit_test_framework.lib
So when we start using boost after doing this (with MSVC only does this happen), these dynamically generated linker statements don't give a rip about or know about what -layout option you built boost with. They will attempt to link in required libraries using the fully mangled naming format, which is why you get the error:
cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
.. because you don't have a file named that! That's the mangled name! You have a file named libboost_unit_test_framework.lib. See the difference! So, you need to tell these stupid macros to stop mangling the library names when auto-linking required libraries. You do that by adding the following preprocessor definition to your Quantlib project:
BOOST_AUTO_LINK_NOMANGLE
You add that in Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions.
If you'd rather avoid this headache and don't care about the long and (imo ugly) mangling that boost does to library names, you can build boost omitting the -layout option and it will default to this mangled naming convention, where you shouldn't get stuck on this error at all anymore. I personally put out the effort to keep nice short/clean library names but it's all about preference.
Edit
Since you have the same error after fixing the NO_MANGLE problem, then the only possible reason that you're getting this particular link error is that you do not have whatever file the linker is complaining about missing stored in any of the directories supplied to the linker.
Verify the folders/paths you provide to the linker and verify that the file the linker is looking for is in one of the directories that you're providing to the linker. You have to provide directories to the linker because you're telling the linker "you can look in all of these places for the libraries my project needs". If you specify none, it's got nowhere to look. :(
Example:
I am building a Visual C++ 6.0 workspace in Visual Studio 2010, so that it'll update some dependencies
I have all the files and dll's it is looking for, it builds but then fails at linking with this error
1>LINK : fatal error LNK1181: cannot open input file '\Projects\exe\CRelease/api.lib'
I have api.dll which it needs to build, but I don't have a .lib file version of it. and even if I did (like if I somehow converted the .dll into a .lib), I wouldn't know where to place it in a directory structure
how do I "fix" this?
guidance appreciated, thank you
Normally api.dll would have an accompanying import library called api.lib which is what you need to link to. The import library is different to a statically-compiled version of api (which would also likely be called api.lib) - it's more like a list of available functions provided by the dll, and so will usually be much smaller than a corresponding static library.
If you do find or get api.lib, it doesn't really matter where it lives, as long as it can be accessed by your linker.
If you don't find the import library, you're looking at doing explicit run-time linking where api.dll is loaded and unloaded explicitly in your code, and api's exported functions are called through function pointers.
I have an application that uses the winInet classes - #include <afxinet.h> and the wininet.dll
I would like to statically link the WinInet function calls in my application as well as the dll, so I followed these steps. I then copied the wininet.dll into my project directory, as I read here.
Upon building I get the following error - wininet.dll : fatal error LNK1136: invalid or corrupt file
My first question is:
-Am I correctly doing what I think is statically linking function calls and the dll?
-If so, why is the dll corrupt with this setup, but works without these changes?
Any help is appreciated. Thank You.
"Static Linking" is the process of including the code in your application. By nature, a DLL is a dynamic link library and therefore no, including the DLL in the directory of your application is not static linking - it remains dynamic. The reason for placing it in the directory of the application is so that the application can find it without the need for install.
I don't suppose it is the DLL that is "corrupt" - I suspect you are attempting to static link the DLL into the application which cannot happen. You need instead to include the correct .lib file, whatever that is, in the additional libraries to link with and ensure that the lib file you link with is not the DLL exports package for wininet.dll
You shouldn't link directly against the DLL. Instead, link against the corresponding import library (should be Wininet.lib). The DLL still needs to be accessible to your application at runtime, of course. The .lib file is needed by the linker to setup proper linkage to the DLL.
Am I correctly doing what I think is statically linking function calls and the dll?
What you're doing is usually called dynamic linkage (more or less dynamic ..), but its (afaik) the only way to go for Windows System APIs. 'Static' linkage would embed the Wininet code directly into your executable, with no need for an external DLL.
When you link with a DLL, there is a corresponding LIB file to use to set up the correct linkage to the functions. For an example, if you are using a USER32.DLL and KERNEL32.DLL, it's corresponding LIBs that needs to be linked would be USER32.LIB and KERNEL32.LIB.
Sometimes it is not so obvious, you can double check by looking at the MSDN for the function in question, when you scroll down towards the bottom of that page it will tell you what library to link with, for an example, look at the Win32API's CreateProcess, as you look at the bottom of the page, it tells you what is the library to use, in this case it's KERNEL32.LIB.
You just referenced a DLL during the linker phase which the linker could not understand the DLL as it is already a compiled library and hence the linker complained that it was "corrupt".
Change that to WinInet.LIB and all should be ok.
Hope this helps,
Best regards,
Tom.
I noticed the following about a library I use:
Library is compiled to .lib file.
My code needs to be compiled as Multi-threaded (Debug) DLL to link to this library.
I open the .sln (solution) file of the library (it is open source) and see the following in its Project properties:
Runtime Library option is set to Multi-threaded (Debug) DLL.
Configuration Type is set to Static Library (.lib)
My confusion is:
Isn't there a conflict in the library options above? (Static Library says one option, DLL says another)
What kind of an animal is a .lib that is dynamically linked? How is it different from a DLL?
Note that I am aware of the difference between static libraries and dynamic libraries in the Linux world.
The "RunTime Library" option isn't about YOUR library. It tells the compiler that you'll import your functions from MSVCRTxx.DLL at runtime.
The "configuration Type" option does refer to your library, and therefore is independent of the "RunTime Library" option.
A Windows DLL can be dynamically loaded with the LoadLibrary (or LoadLibraryEx) API, but then you have to find and bind each exported function to a function pointer using GetProcAddress or GetProcAddressEx. You'd better get the function signatures right, or Bad Things Will Happen, as usual.
A LIB file allows Windows to do all that for you when your EXE is started (including finding which DLL to use, and recursively loading dependent DLL's), linking the dynamic library statically at run time, while avoiding bloating your EXE file with the executable code, and allowing several processes to share the same DLL image in memory.
I don't know about the config mismatch, but a .LIB file when created with a .DLL library is an "export library" - it doesn't contain any code, but just the names of the callable functions and objects in the DLL. The linker uses this to satisfy references at link time which are finally resolved by dynamic loading at run-time.