I have built OpenCV (dynamic libs) with TBB support using CMake and VS2010. However, for the integration of my plugin (that uses opencv calls) in an external host application, i have to rename the tbb.dll, since the host application already includes a tbb.dll but using a different version.
I read that DUMPBIN and LIB commands can be used to obtain the list of export symbols for the dll to create an import library. However, according to http://support.microsoft.com/kb/131313/en-us this is only possible for export functions using a C interface, but the Dependency Walker shows that both C and C++ interfaces are used.
So, is there a "simple" solution to rename the tbb.dll afterwards (i.e. after OpenCV was compiled)? Or do you have any hints how this can be accomplished?
Thanks in advance!
It's not a nice solution, but it is possible to patch dll-s! Eg. replace any reference to tbb.dll in a dll to tbc.dll. You can just use a hex editor for this, or write a script.
Related
I have an existing third-party static library that I want to use in my project C++WinRT UWP app. Can I do that?
I have read the documentation. But it has me confused.
Documentation talk about "Using a native C++ static library in a UWP App" what is a native c++ library?.
Also, I do not have the source code for this library.
The primary limitation for UWP is that the library:
(a) Must use the subset of Win32 imports that are supported for use in WINAPI_PARTITION_APP
(b) It needs to have been built with VS 2015 Update 3 or later in order to be 'binary compatible' with modern Visual C++ tooling used for UWP.
(c) Some APIs that are used by the static library may not be supported in the "AppContainer" security context (i.e. they may fail in ways the code doesn't handle gracefully).
You should also use /NODEFAULTLIB:kernel32.lib to avoid having your static library force the import of non-supported APIs. The "WindowsApp.lib" umbrella library provides everything that's supported.
More than likely, you'll need the static library built with some modification to actually link successfully and eventually pass WACK.
I have an existing third-party static library that I want to use in my project C++WinRT UWP app. Can I do that? Also, I do not have the source code for this library.
Yes. You don't need the source code to use a library.
You can just use the binary library ( the final output from the source ) that is provided. It can be included as either a static or dynamic library in your final output binary.
How to include that?
Referring to some portion from the doc for your third party static library that may help.
To use a native C++ static library in a UWP project
In the project properties for the UWP project,
choose Configuration Properties > Linker > Input in the left pane.
In the right pane, add the path to the library in the Additional Dependencies property.
For example, for a library in the project that places
its output in <SolutionFolder>\Debug\MyNativeLibrary\MyNativeLibrary.lib,
add the relative path Debug\MyNativeLibrary\MyNativeLibrary.lib.
Add a include statement to reference the header file to your pch.h file (if present),
or in any .cpp file as needed, and start adding code that uses the library.
C++
Copy
#include "..\MyNativeLibrary\MyNativeLibrary.h"
I have query related to how to use OpenSSL project in my C++ application.
I saw there was one installer that was registering the library and then we have to use this library in our application.
But actually I have my own project where I want to use openssl .c and .h files without using dll.
How can i do this?
Normally using DLLs is a good idea because it will enable others (that don't have your sourcecode) to update the openssl version in use by your program.
When we consider the plethora of security issues from the last months this is a good thing ...
If you still want to statically include the openssl code into your program you can do so by including the files into your project and calling them directly.
See stackoverflow for examples, this might be one that fits your scenario: How do I build OpenSSL statically linked against Windows runtime?
When we build the opencv library, either in a dynamic way or in a static way, we will produce several separated libraries. Take the 2.48 version for example, we will have
opencv_core248 opencv_imgproc248 zlib IlmImf comctl32 opencv_highgui248 libpng
and so on. So my question here is clearly there are some dependencies between these libraries, for example, if I want to invoke opencv_core248 and opencv_imgproc24 library in a project, I have link errors. Then, if I add zlib library, the compilation error will be solved.
Question: I want to ask a very general question: how can I know the dependencies between all the libraries insider opencv? Are there some documents I can follow? Thanks.
I don't think there is a document listing all the dependencies between the OpenCV libraries.
However I can suggest two methods to find out these dependencies:
Using Dependency Walker, a free tool allowing to analyze executables and DLLs. For instance, if you open opencv_calib3dXXX.DLL (where XXX represents your OpenCV version), you'll see that it requires opencv_coreXXX.dll, opencv_flannXXX.dll, opencv_imgprocXXX.dll and opencv_features2dXXX.dll and some system DLLs.
Using the project structure generated by CMake, a free tool for cross-platform compilation which is used for compliing OpenCV from sources. For instance, if I generate the project structure for VS2010 and open it, I can right-click on the project associated to opencv_calib3d and view the project dependencies.
I mentionned the tools I know and use for Windows, but equivalent tools must also exist for other platforms.
I have a few NT imports I want to use in my program, problem is I am unable to use them without going though the lengthly process of downloading and setting up the WDK to use just two functions. I would also prefer not to use GetModuleHandle and GetProcAddress.
I know in VB6 you can manually define imported functions from dlls like this:
Private Declare Function NtFunction Lib "ntdll.dll" (function arguments) As type
Is there something similar I can do with C++ in Visual Studio without having all the headers/libs?
You say you don't want to use GetProcAddress, but that's exactly what VB6 Declare Function (and .NET p/invoke) does.
You do need a complete prototype, often you can recreate enough of the header file from documentation.
The import library is a little more difficult, but there are tools to create import libraries from the .DLL.
If you create a .DEF file, you can use the LIB.EXE tool that comes with Visual C++ (and also available as a free download as part of the Windows SDK), see Building an Import Library
Here is some more information.
mingw comes with a tool for mostly automating creation of the .DEF file: http://www.mingw.org/wiki/CreateImportLibraries (the import library it creates is only usable with gcc, but the .DEF file is useful for making a VC++ import library as described above).
Here's a another tool that might help: http://www.codeproject.com/KB/tips/ImpDef.aspx
I'm in the process of porting a large C++ application from Linux (gcc) to Windows (Visual C++ 2008) and am having linker issues with plugins. On Linux this wasn't an issue, as .so supports runtime symbol lookup, but dll does not seem to support this.
Some background information:
The application (the host), which hosts a scripting environment, provides interfaces to plugins (shared libraries that are loaded at runtime by script API calls), allowing the host and the scripting API to be extended without recompiling the host application. On Linux this is just a matter of including the host application's headers in the plugin source, but on Windows I'm receiving linker errors. I'm not sure exactly what I need to link with for Visual C++ to resolve these symbols.
One of our dependencies (open source, LGPL) has preprocessor declarations that it uses to insert __declspec(dllexport) and __declspec(dllimport) into it's headers. Some prior research indicates that I may have to do this as well, but I'd like to be sure before I go modifying a whole bunch of core headers. (I was previously able to get this working on MinGW, but we've decided that supporting Visual Studio is a requirement for this sort of commercial project.)
My question, in a nutshell: How do I link runtime-loaded dlls against a host exe in Visual C++?
Edit: To clarify the problem with an example, I have a class in my host application, Object, which represents the base type of an object that may be accessed by a script. In my plugins I have a number of classes which extend Object to perform other functions, such as integrating networking support or new visual elements. This means that my dll must link with symbols in the host exe, and I am not sure how to do that.
What do you mean by "runtime symbol lookup"? Do you mean dynamically loading libraries using dlopen and dlsym and so on? The equivalents in Windows are called LoadLibrary and GetProcAddress.
In windows, you don't export symbols from a executable. You should only export them from a dll. The right way to solve your problem is to rearchitect so that the exported symbols are in a dll that the executable and other plugin dlls can link against.
You can't, easily. The windows loader isn't designed to export symbols out of an EXE and bind them to symbols in a DLL.
One pattern that I have seen is the DLL export a certain function that the EXE calls. It takes as a parameter a structure which contains addresses of functions in the EXE for the DLL to call.
I have been implementing the same, constructing a plugin library to build under both Linux and Windows.
The solution under Linux is to use the -rdynamic option in the gcc command line. This exports all of the symbols in the main executable, so that a plugin can find them on loading.
Under Windows, the solution is to add __declspec(dllexport) in front of the definition of those functions in the exe that you want the dlls to use. Compilation will create a .lib file for the dlls to link to. Certainly works under Visual studio 2008.
Related post: https://stackoverflow.com/a/3756083/1486836
As 1800 INFORMATION says, don't do it like that. Move Object out of the executable and into a "third" DLL. Link the plugins and the executable against that.