I have a windows dll (Main application directly loads this windows dll) that links to another 2 dlls, which are obtained by cross-compiling using mingw32.
I am facing a weird problem with this linking.
Say I have 2 functions in first cross compiled dll funcA_firstdll() and funcB_firstdll()
and similarly I have 2 functions in second cross compiled dll funcC_secdll() and funcD_secdll().
When linking with windows main dll I dont get any linker errors but the dlls are not getting loaded.
So if I check the dependencies of windows dll using dependency walker I see both the first and second cross compiled dll in red colour.
When I click on first cross compiled dll I am seeing the functions present in that dll(funcA_firstdll() and funcB_firstdll() ) as green and second cross dll(funcC_secdll() and funcD_secdll()) as red.
Similarly When I click on second cross compiled dll I am seeing the functions present in that dll (funcC_secdll() and funcD_secdll()) as green and first cross dll as red.
I am unable to understand why are they unable to interlink with each other.
Is there any different way to link cross compiled dll's.
Any help is appreciated.
Regards,
Techtotie.
Solved it by myself.
It was actually a problem with proxy libs generated by mingw were not interpreted properly by MSVC.
So had to generate the def files also. Follow this tutorial
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
Related
Scence:
One MFC program depends on msvcr90.dll and mfc90.dll,I copy those depended DLL to the program directory,program still can't execute.However,the program was executed successfully after I had installed the vcredist_x86.exe.
Miraculous is I checked the dynamic library dependencies of this program again with depends.exe,it automatically linked to dynamic library under fixed path.The path like:c:\windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.21022.8_none_b81d038aaf540e86\MFC90.DLL,c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9415_none_508df7e2bcbccb90\MSVCR90.DLL.
Even, I deleted the DLL under those path and it still linked to there.
What have I installed vcredist_x86.exe,which bring about linking to dynamic library under fixed path, e.g.MFC90.DLL,MSVCR90.DLL?And why I copied don't work?
Came across the following paragraph from a page on the MySQL website here:
You can write plugins in C or C++ (or another language that can use C
calling conventions). Plugins are loaded and unloaded dynamically, so
your operating system must support dynamic loading and you must have
compiled the calling application dynamically (not statically). For
server plugins, this means that mysqld must be compiled
dynamically.
What is meant by dynamical compiling? I know about dynamical linking, but I'm not sure what they meant with dynamical compiling.
Also, on Windows 10 (x64), how can I assure that an exe has been compiled dynamically? Is it possible to figure it out from the output of dumpbin? Here's the dumpbin output for mysqld.exe (version 5.7):
Note: I reviewed this old question which did not provide me with that much information. The depends tool it suggests is no longer on Windows.
Compiling dynamically simply means that you are compiling the code such that the compiled output is suitable for dynamic linking.
On Windows, the process of creating as DLL necessarily compiles it such that it's suitable for dynamic linking because DLLs are always dynamically linked.
I believe that most platforms today always compile dynamically and produce relocatable output, even if they're subsequently linked statically.
I'm looking at incorporating Lua into a C++ project, and am a bit confused by the presence of the two binaries (lua51.dll and lua5.1.dll) in the distribution from Luabinaries.
According to the docs...
In Windows your library or application
must be linked with a stub library. A
stub library is a library with only
the function declarations that will
bind your DLL with the Lua DLL.
Why? I've never needed stub DLLs before when linking with third-party DLLs?
A stub library is a .lib file, not a DLL. It contains function declarations for all the exported functions in the DLL, which just forward the call into the DLL itself. So if you build an application that you want to link with lua51.dll, you tell the linker to link with lua51.lib, and all calls to exported functions will be forwarded to the DLL. If you didn't do this, you would get a lot of "unresolved external symbol" errors when linking.
This is only needed when statically linking with a DLL (so that it is loaded automatically when the application is run). It is not needed when loading the DLL dynamically with LoadLibrary.
Regarding why they have two different DLLs, The manual says this:
The LuaBinaries DLL packages have a dll proxy called "lua51.dll". It can be used to replace other "lua51.dll" released by other distributions. It will simply forward calls to the "lua5.1.dll". There is no compiled source code involved in the forwarding.
Basically, some existing applications link with lua5.1.dll while others link with lua51.dll and they want to support them both. In any case this is not related to the stub libraries.
I believe it's to do with __declspec(import) and __declspec(export) vs GetProcAddress. However, I don't actually know for sure.
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;'
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.