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"
Related
I am new to programming in C++ on Universal Windows Platform and I have a quick question: I created a project of Static Library (Universal Windows) in Visual Studio 2015 but I couldn't use those Windows Runtime classes such as Windows::UI::Core::CoreWindow in that project.
I guess I need to add include directives or references to libraries but I couldn't find information about that. I tried to search MSDN but just found two pages where two headers were mentioned for namespace default and Collections.
Does anyone know how to reference Windows Runtime classes in a Static Library?
You need to build the project with the /ZW option to allow consuming Windows Runtime Extension in a UWP Static Library:
Right click on the project from Solution Explorer
Click Properties
Select C/C++ -> General
Set the "Consume Windows Runtime Extension" to "Yes(/ZW)"
Click OK
After applying this option, references to Windows Runtime Extensions appear under the references of the project and you can use Windows Runtime Classes.
However, you may see a linker warning while building the library:
Debug\pch.obj : warning LNK4264: archiving object file compiled with
/ZW into a static library; note that when authoring Windows Runtime
types it is not recommended to link with a static library that
contains Windows Runtime metadata if you are using a linker released
before VS 2015 Update 2
I tested the scenario and it worked fine in debug mode, however, I'm not sure if it is the best way since the /ZW option is off by default unlike other types of UWP projects.
MSDN:
You can use a native C++ static library in a UWP project, but there
are some restrictions and limitations to be aware of. Start by reading
this topic about static libraries in C++/CX. You can access the native
code in your static library from your UWP app, but it's not
recommended to create public ref types in such a static library. If
you compile a static library with the /ZW option, the librarian
(actually the linker in disguise) warns:
Maybe you should consider wrapping all the code in a Windows Runtime Component or a UWP DLL instead.
I'm developing a cross-platform application that uses few shared libraries (also developed by me). I need to ensure that application is loading correct versions of that libraries at runtime. i.e. if user has specified path to some old version of shared library in config file application has to be able to detect this fact, do some logging and terminate. What is the best way to implement this? I'm sure that this problem is not new and there has to be some standart, "best-practice" solution.
The one solution I can think of is following:
Use version.h files in app and libs, during build step write same version values to both version.h files.
Implement getVersion() method in library, which will be used by application after loading library to ensure that library has expected version.
Any alternatives?
I have created test C++ static library in VS and I am using boost in that.
Now this static lib is used/linked in DLL I have created. Now I want to link this DLL in a c++ console application.
Static lib and DLL both compiles fine. When I am using this dll in console application, I am getting error in static lib's header file that can not open include file #include "boost/config.hpp"
I copied static lib's header and dll's headers in console application and linked through properties/linker/additional library directores
I really dont want any user who are using my dll to link with boost and all. I just want to supply dll and they should be good to use it.
Please guide me. I am dealing with DLL and static lib. for the first time.
So If I include all boost headers in my application, it should be good to use. Is there any other solution?
The header files from your static library are including boost. When you include these in your application, the compiler is looking for the boost includes as well. If the boost declarations are not a part of your library interface, then these includes need to be moved out of header files referenced by your application.
I really dont want any user who are using my dll to link with boost and all. I just want to supply dll and they should be good to use it.
That's pretty much tough, not least because most of Boost is header-only.
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.
I am trying to expose a single well defined class by building a static library and then shipping the built library with a few header files that define that class and the interfaces needed to use it. I have that working but the problem I am running into is the library is gigantic. It has every single object file from the whole project and all I need is a subset. If I make a simple main.cpp file and include and use that single class then I get a output file that is only as big as the 20% of the library I am using. Is there a way to tell the linker to start from a given place and prune everything else like in the executable case?
EDIT: I forgot to mention that I am using gcc on cygwin and linux (though I would like a solution that worked with visual studio as well, we generally use that for development but deploy primarily on linux)
Make a shared library. It behaves like an executable from the point of view of linking etc. It should do the discarding you mentioned you saw on the executable.
You have to split the project up. Take out the files needed for the library and make that a separate project just building the lib.
The remaining project (with main.cpp in) needs to call the new lib project to get the lib
Details depend on what tools and OS you are using to manage the project (e.g. Visual Studio or make or ... )
You haven't told us what toolchain you are using but since you say project, I'm guessing you are using the MS toolchain.
The MS toolchain includes every object from a project into the static library. What you want to do is break your single class into a separate project. You can continue to have a super-project that includes that class so you don't have to modify any of your existing projects.
Now, if you want to take this to the next level, you should consider putting each member of the class into it's own translation unit (i.e. .cpp file). This way, if a user of the class only needs a few parts of the class, they will only need to link in the parts they need.