On Firebase CPP SDK website, it states:
For Windows, library versions are provided based on the following:
Build platform: 32-bit (x86) vs 64-bit (x64) mode
Windows runtime environment: Multithreaded / MT vs Multithreaded DLL
/MD
Target: Release vs Debug
But the build they have provided have no DLL files, and only Lib files, when i link the Lib files, the project works fine, how is it possible that it does not ask for firebase DLL?
Donnot need dll at run time when link to a static library.
Here is what I found :
enter link description here
A static library (also known as an archive) consists of routines that are compiled and linked directly into your program. When you compile a program that uses a static library, all the functionality of the static library that your program uses becomes part of your executable. On Windows, static libraries typically have a .lib extension, whereas on linux, static libraries typically have an .a (archive) extension. One advantage of static libraries is that you only have to distribute the executable in order for users to run your program. Because the library becomes part of your program, this ensures that the right version of the library is always used with your program. Also, because static libraries become part of your program, you can use them just like functionality you’ve written for your own program. On the downside, because a copy of the library becomes part of every executable that uses it, this can cause a lot of wasted space. Static libraries also can not be upgraded easy -- to update the library, the entire executable needs to be replaced.
Related
I understand that /MT compiler option causes the application to use the multithread, static version of the run-time library.
Suppose my solution consists main project PrjMain as a Win32 console application, and a PrjLib compiled as static library, both using \MT. Will the CRT be linked into the final PrjMain.exe twice -- once by the PrjMain, once via PrjLib as a static libary?
The CRT will only be linked in once. Both the main project and the PrjLib library will link to the same static CRT, as long as both the project and library are compiled into one binary.
Where problems come from are when mixing a module that uses a static CRT with one that uses the DLL CRT in one binary, or when using multiple binaries (an executable and a DLL) that both use the static library. In those cases you'll get two copies of the CRT loaded, which can cause problems.
Quick question here, okay say that I have downloaded additional libraries and added them to my version of visual studios and have their #include and commands in my project source code.
If I was to take the .cpp file and bring it to my school computer which also has visual studios and doesn't have these additional libraries, it would have a bunch of missing errors and can't compile.
but..
What if I publish my project and I have it in a .exe file and I was to try and run it on another computer that doesn't have these libraries? Would the executable file run okay?
When you
#include <stuff>
stuff is used during compilation time. However, the libraries it may refer to (e.g. the include gives the definition of many functions from an external library), can be
static or
dynamic
static libraries are linked statically when the program is built, and are part of the executable. dynamic libraries like DLL are linked during the execution of the program .exe. Thus they (DLL) may not be present on another computer when you run the same exe on it.
It depends on the libraries you are using, but sometimes a package is available for download and installation on the other computer, so that they become available. Sometimes you have to copy a bunch of DLLs along with your exe to the other computer. For instance, some advice from Microsoft in this regard.
Well, trying to build a simple exe in visual studio 2012, with c++ win32 console app, just with a
printf("-----");
After build the release version, its running ok.
When transfer to another windows 7 clean installation, at running i get notice that the MSVCP110.DLL is missing...
Its not a native app ??? why extern dll is needed ?
In old win95 I make many executables with visual C 6 and its run standalone withou any dll.
I will always deplay this dll's with the "native" exe ?
When you write a C++ program, you use a few low-level libraries to interface with the machine. The C++ Standard Library is one example. Consider for example, new. When you call new in your program, you're invoking a piece of code that implements that functionality. Where is that actual code?
It's in a library. That library is deployed in a few different ways. One way is through dynamic linking, where the library is in the form of a DLL that needs to be present on the machine where you run your program. That's what MSVCP110.DLL is -- it's one of the library files your program was compiled against. Another way is to use static linking, where the code from that library is compiled directly in to your program. This results in a signifigant increase in the size of your application, but the other side of that coin is you don't need those library files to be on your target machine. You also need to make sure that other libraries your program use are also built against the same static library. If your program shares data with other programs, you further may need to ensure that those programs use the same static libraries.
Microsoft and Windows aren't unique in this. The same thing happens under Linux, albeit the libraries have different names.
There are pros and cons to using either shared libraries (eg dynamic linking) or static libraries. It's simple and catchy to say "gahrrr I hate shared libraries" but unless you understand why either is appropriate in what situation you stand to deploy a poorly-designed program.
I'm working on a C++ solution in Visual Studio 2010. I've a DLL file which is using some standard C++ library functions (such as string or file functions). For some portability reasons I have to compile this DLL with /MT option, so all required runtime library functions will be linked to the released DLL file.
I've another C++ project which is a windows application, this project also compiles with /MT option and generates an standalone exe file. The second project also uses the same standard C++ library functions that are already linked in my DLL (The executable also uses some DLL exported methods).
Now here is my question: Is there any way to tell linker that don't link common runtime functions which already linked to DLL file & don't link these shared parts again in the exe file (e.g. reuse same code for string functions which already linked to my DLL)?
No, you can't do that. Although executable depends on DLL, they can still be considered as separate and stand-alone binary artifacts, each of which should contain required symbols for proper execution.
This is one of the reasons why dynamic linking is preferred. Furthermore, I don't see any problem to link dynamically and redistribute the runtime with your application.
Although Microsoft Visual C Runtime is included on most platforms, there are many different versions of it, some of which are buggy or/and break backward compatibility. Thus, it is always a good idea to distribute the version of msvcr*.dll that you know works for sure with your application.
I'm working on a library project which is pretty much finished. So I'm giving it a test run now. I have no problem running my test project. However I'm not entirely sure if I'm doing it right. Mainly because I don't really understand what is happening exactly( at least im not entirely sure).
I've compiled both the DLL and Static library(.a). For my test project i'm using the Headers from my library and linking against the static library. I'm able to compile. But then It seems that I also need the DLL where the executable resides in order for it to run.
So to my understanding, I compile using the static library but I don't exactly embed it into my executable, therefor at runtime it's looking for the DLL?
My confusion comes from the fact that I read that static libraries are usually embedded into the executable. But doesn't that only happen if you specify that in the compiler options?
I'm rather confused about the relationship in my sittuation. Can someone clarify this?
Edit:
I'm using GCC.
Codelite as my IDE.
lib is static (cannot be dynamically linked at run time) at compile time. So you are correct that the lib is "embedded" in the executable. More precisely, the lib is linked to other object files that the compiler has produced to build the exe file. A lib cannot link to another lib, only an exe or a dll can link to a lib.
dll is dynamically linked by the exe while the exe is run. dll is like another exe, but its entry function is "dllmain" instead of "main". dll can be built with lib's just like exe. dll can also link to other dll's at runtime to interface with these dlls' functionalities. The interface to dll is defined by a def file.
As to why your project would need the dll, you might want to check the calls of LoadLibrary in your project.