There are (static?) library L - VC++ runtime, a program EXE, that uses functions from L, and a dll library DLL, that also uses function from L. EXE also uses functions from DLL.
On PC there is no C++ redists, I statically linked L to EXE. DLL has not been statically linked with L.
EXE runs some function from C, that uses function from L.
Will it fail, and hence I need either to also statically link L to DLL, or install redistributable package?
Specific example:
I have dll library that needs VC redistributables to be installed on the system, as I understand, as bunch of dlls.
I want to run some program, that uses my dll, on PC where VC redist is not installed, and I do not want to attach installation file, I just want my program to run on click.
So the solution is to statically link vc runtime in Visual Studio, but can I link only to exe, and it will share it with my dll, or do I need to statically link dll as well as exe?
My thoughts:
I think it will not work because: if vc runtime static link is not turned on in DLL project properties in Visual Studio, then, I suppose, in vc headers, imported function will be as variables, with values obtained from GetProcAddress, as in plain dynamic linking:
some_vcruntime_header.h
#ifndef RUNTIMESTATIC
typedef void (*MEMCOPY)(void *, const void *, size_t);
HINSTANCE vcruntime = NULL;
MEMCOPY memcpy;
vcruntime = LoadLibrary(L"path/to/vcruntime140.dll");
memcpy = (MEMCOPY)GetProcAddress((HMODULE)vcruntime, "memcpy");
#endif
…
And if vs runtime is linked statically, then it will not look for the dll, and header will have just a function definition, not as variable:
…
#ifdef RUNTIMESTATIC
void memcpy(void*, const void*, size_t);
#endif
If my assumption is correct, then by statically linking L to EXE, the DLL without static link of L and loaded by EXE, still will be searching for dlls versions of vc runtime.
Short answer.
It's unknown and not guaranteed to work, unless documentation for A (including its source code) states otherwise. Whole "will it work" depends on what library does.
Long answer.
DLL is a separate executable module, which differs from a program by the entry point used. It got secondary entry points - exported functions you use.
If both modules are linked statically with library A, they use separe instances of A's functions and variables. If A contains a singleton or a global variable, each will have own instance.
In fact, this can be abused to create "objects" by loading additional instances at run-time by LoadLibrary. The author of this text did it in past to port Fortran program's functions and common blocks into a C++ program. Then loading and running each instance would not change data in another, less data copies required and allocated memory would be freed with DLL.
Library can be designed to work around that issue, but it's rare a and it's documented as a supported feature. Some libraries can be compiled as DLLs by design, some have infrastructure that checks if another instance is imported from another DLL. In some cases it's a non-issue because library does not contain own stateful objects.