I've been trying to create a static library (.lib) with some DSP classes of mine. The DSP classes use the Eigen library which in turn utilizes MKL and IPP.
My issue is that I can't find a way to create this static library that will be a "standalone", i.e. if I create an application project, I will only need to include my own DSP library .lib file and it's header file(s).
When I try to create a static library out of the static versions of IPP and MKL I get a LNK1189 error that the number of allowed symbols are exceeded.
So far the only thing that works is using the dynamic versions of IPP and MKL and of course adding the redist paths of IPP and MKL to the Windows environment path variable. Sadly, that cancels the whole point of using one set of header files (my own, that reference ipp headers) and my .lib file.
I will be more than happy to elaborate if it is not clear what I am trying to do.
Any help would be really appreciated.
Do you mean dynamic library build of your static library (your classes) and static IPP/MKL? So, you can't build your custom dynamic library because of 64K limit of symbols in DLL exceeded? Because, LNK1189 is a linker problem.
Regarding IPP, the simplest way I see to refuse from including of numerous CPU optimizations to your dynamic lib. There is a way to say compiler/linker what to take from IPP.
Look at tools/staticlib directory in your IPP installation, at readme file there. There is a description of what to do to minimize the size, and in turn, the number of public symbols in custom DLL.
But, using this method you can prepare your DLL for only one CPU architecture, say SSE42, or AVX, because there will be no CPU dispatcher in your DLL.
Regards,
Sergey
Related
I know similar questions have been asked, but it's still unclear to me.
I have written a library with multiple drivers and modules for Zephyr RTOS. Now I would like to share part of that library with a company, but not as source code. The idea is to compile the relevant source code for the specific hardware they have, and then share it. This way I can control for which products it's used, and of course I don't want to share my source code with them.
At first I have tried just sharing a static library, but that didn't compile for them. Shared libraries are not yet supported by Zephyr's CMake extensions, hence I haven't tried that yet. If it's the way to go I will dive into it.
What are my options? Shared library vs. static library (+ object files?)? What is recommended?
More info
Zephyr uses Device Trees. Hence, the drivers / modules I provide are compiled for a specific hardware target. I would like the company to provide me with the relevant hardware definitions so that I can provide them a pre-compiled library of my drivers/modules that works for their specific target. This library might have to be updated sometimes to include bugfixes / new functionality.
As the binaries are compiled with application + library, what would the trade-off be for Static vs. Shared library?
I think shared libraries and header files is the way to go . As they offer advantages. Like smaller binary size and flexibility to update. You can find a nice description here.
https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
C++ recommends using shared libraries because it provides flexibility on Linux or Linux like systems
https://www.bogotobogo.com/cplusplus/libraries.php
I compiled OpenCV 3.x with the Static Libraries options (-DBUILD_SHARED_LIBS=OFF).
No I have a project built with few functions which uses OpenCV.
I want to build my project as a portable static library.
By portable I mean I can share it with others to use my functions in their code without the need to install OpenCV.
How can I do that on Windows, macOS and Linux?
I would like the process to be done using a Compiler in order to extract only the needed objects (Functions) from all OpenCV libraries.
How is it different from other questions on the subject?
The difference in my question versus the generic answer of archiving multiple static libraries into one is the selection of which functions to include.
Let's say we have 2 static libraries - lib001.lib and lib002.lib.
Where lib001.lib has the functions fun001(), fun002() and fun003() and lib002.lib has fun004(), fun005() and fun006().
Let's assume the functions has dependency which I'm not aware of (I didn't write the libraries). So in my project I use fun001() and fun005() and let's say fun001() depends on fun004() and fun005() depends on fun002().
What I'd like is the linker to understand this and build me a custom static library which includes my functions and fun001(), fun002() fun003() and fun004() without me telling the dependency.
Remark
Above I assume each object in the static library is a function. One could replace the use of functions by objects to be more accurate.
If you wish to compile OpenCV on a static manner on all the 3 platforms you mentioned, I would suggest to use conan.io package manager (here is the conan-opencv package), by issuing the command:
conan install opencv/4.1.1#conan/stable -o shared=False --build=missing
And from there, using conan in your project and make a final static executable.
Here is the official documentation of Conan, complete with examples.
In your case, your conanfile.txt will have the follow content:
[requires]
opencv/4.1.1#conan/stable
[generators]
cmake
[options]
opencv:shared=False
I know these questions have been asked before - but I still can't reconcile everything together into an overall picture.
static vs dynamic library
static libraries have their code copied and linked into the resulting executable
static libraries have only copy and link the required modules into the executable, not the entire library implementation
static libraries don't need to be compiled as PIC as they are apart of the resulting executable
dynamic libraries copy and link in stubs that describe how to load/link (?) the function implementation at runtime
dynamic libraries can be PIC or relocatable
why are there separate static and dynamic libraries? All of the above seems to be be the job of the static or dynamic linker. Why do I need 2 libraries that implement scanf?
(bonus #1) what does a shared library refer to? I've heard it being used as (1) the overall umbrella term, synonymous to library, (2) directly to a dynamic library, (3) using virtual memory to map the same physical memory of a library to multiple address spaces. Can you do this only with dynamic libraries? (4) having different versions of the same dynamic library in memory.
(bonus #2) are the standard libraries (libc, libc++, stdlibc++, ..) linked dynamically or statically by default? I never need to dlopen()..
static vs dynamic linking
how is this any different than static vs dynamic libraries? I don't understand why there isn't just 1 library, and we use either a static or dynamic linker (other than the PIC issue). Instead of talking about static vs dynamic libraries, should we instead be discussing the more general static s dynamic linking?
is symbol resolution still performed at compile-time for both?
static vs dynamic loading
Static loading means copying the full executable into MM before executing it
Dynamic loading means that only the executable header copied into MM before executing, additional functionality is loaded into MM when requested. How is this any different from paging?
If the executable is dynamically linked, why would it not be dynamically loaded?
both static loading and dynamic loading may or may not perform relocation
I know there are a lot of things I'm confused about here - and I'm not necessary looking for someone to address each issue. I'm hoping by listing out everything that is confusing me, that someone that understands this will see where a lapse in my understanding is at a broad level, and be able to paint a larger picture about how these things cooperate together..
why 2 types of lib loading
dynamic saves space (you dont have hundreds of copies of the same code in all binaries using foo.lib
dynamic allows foo.lib vendor can ship a new version of the library and existing code takes advantage of it
static makes dependency management easier - in theory a binary can be one file
What is 'shared library'
unix name for dynamic library. Windows calls it DLL
Are standard libraries static or dynamic
depends on platform. On some you can choose on others its chosen for you. For example on windwos there are compiler switchs to say if you want static or dynamic runtimes. Not dont confuse dynamic library usage with dlopen - see later
'why we talk about 2 different types of library'
Typically a static library is in a different format from a dynamic one. Typically a static library is input to the linker just like any other compile unit. A dynamic library is typically output by the linker. They are used differently even though they both deliver the same chunk of code to your app
Symbol resolution is finalized at load time for a DLL
Full dynamic loading. This is the realm of dlopen. This is where you want to call entry points in a library that might not have even existing when you compiled. Use cases:
plugins that conform to a well known interface but there can be many implementations (PAM and NSS are good examples). The app chooses to load one or more implementations from specified files at run time
an app needs to load a library and call an arbitrary function. Imagine how , for example , how a scripting language can load and call an arbitrary method
To use a .so on unix you dont need to use dlopen. You can have it loaded for you (Same on windows). To really dynamically load a shared lib / dll you need dlopen or LoadLibrary
Note that statically linked libraries load faster, since there is less disk searching for all the runtime library files. If the libraries are small, and very unusual, probably better to link statically. If there are serious version dependencies / functional differences like MFC, the DLLs need different names.
The background is following: there is 3'rd party provider that provides us with a libveryfancylib.so, in 32b. Softaware that uses the library has quite a load of other linux library dependencies (like QT) also, but they are open source, so no problem for statical linking. The target platform is 64b and running Debian 7.
We can ship the program with binary + dynamical libraries, no problem, but i would rather see single static binary with no dependencies.
So my question is: why i cannot link the dynamical library into static binary? I mean what bit of information is there missing, or is it just feature that is rarely needed -> not implemented.
We can ship the program with binary + dynamical libraries, no problem, but i would rather see single static binary with no dependencies.
What is the problem you are trying to solve?
You can follow the model most commercial applications on Linux do: put your executable, shared libraries and other resources in one directory (possibly with subdirectories). When linking your executable against those shared libraries pass -Wl,-rpath,'$ORIGIN' (in make use -Wl,-rpath,'$$ORIGIN') to the linker, so that when starting your application the runtime linker looks for required shared libraries in the same directory where executable is.
Then archive that directory and give it to your users.
There are programs for MS Windows that can do so, eg DLL to Lib and DLL to Static Lib.
In the open source world, there isn't really much of an incentive to develop such a tool as you can always recompile from source (but of course it's possible that someone somewhere did it anyway).
It's because dynamic libraries and static libraries are two different things. A static library is just an archive of object files (much like a zip archive). A dynamic library is more like an executable program.
So you can't really link anything into a static library, you can only add more object files.
The shared library is causing much trouble for me, and disk space is far less expensive than the trouble itself.
How can I convert all shared libs(.dll) to static libs(.lib) and make my programe use them instead of using shared libs?
Note some .dlls are not directly refered to by my programe,e.g. my programe requires libpng,and libpng requires zlib.dll.
Is there a solution that wraps up all these cases?
You cannot convert a shared library (dll) to a static library (lib). The dll contains headers, exports, and such things that make it completely impossible to do.
If you have access to the source, you can usually recompile it as a static library. Otherwise, you will have to get your hands on the static library yourself.
There is no practical way to convert DLLs to static libraries. You will either need to find the actual static libraries, or you will need to build them from source.