1

We have a static map which is defined in the static library.

This static library is linked to a dynamic library.

The executable links static library as well as the above dynamic library.

Two questions?

a) Is the static library code duplicated?

b) Will there be multiple copies of the static map defined in the static library? (Can this lead to crash at the time of exit of the executable)

jainsuyogj
  • 33
  • 4

1 Answers1

2

Static libraries are linked at compile time, whereas dynamic libraries are linked at run-time. That said, each piece of compiled code must have the static library baked into it - the library in question will be statically linked to both the .exe and the .dll.

That is, when the DLL is compiled, it receives its own linkage and copy of the static library in question. The executable, using the static library, also receives its own copy of the static library upon compilation.

For this reason, both the .dll and .exe will have their own separate instance of the static library running. So, any variables made with the static lib in the .exe will be independent of the ones made within the .dll, and will not be freed because the two copies will not interact.

alteredinstance
  • 587
  • 3
  • 17
  • 1
    I'm not sure but I think the resulting program ends up having undefined behaviour actually – Lightness Races in Orbit Jan 15 '20 at 16:17
  • @LightnessRacesBY-SA3.0 DLLs are not governed by the C++ standard so it's not quite clear who defines UB in this case. But yes, it's generally not expected behavior that e.g. function-local statics differ depending on which module you're calling the same function from. – Max Langhof Jan 15 '20 at 16:22
  • @LightnessRacesBY-SA3.0 Having researched this in the past it's still somewhat ambiguous, so it might be. This [post](https://stackoverflow.com/questions/19373061/what-happens-to-global-and-static-variables-in-a-shared-library-when-it-is-dynam) actually says there will be only one globally static variable at the time of the dll linkage. OP of this post is saying ODR is applied at the time of linkage, perhaps? – alteredinstance Jan 15 '20 at 16:23
  • @MaxLanghof The resulting program - no matter how its pieces are linked together - should still be governed by the ODR, I'd say. Regardless I kind of meant in the broader sense anyway – Lightness Races in Orbit Jan 15 '20 at 16:27
  • Yeah @Mikael's answer there looks pretty good at a glance. Sounds like it should be okay then – Lightness Races in Orbit Jan 15 '20 at 16:28
  • Also, just my own thoughts here, while the .dll is loaded within the address space, how would the .exe know of the static variable linked within the .dll if it couldnt know before-hand? I'd think that because the only points of access to the .dll are by the pre-defined entry-points, the .exe wont care about the .dll's libraries, and vice versa. therefore the .dll would operate completely independently. Thoughts? – alteredinstance Jan 15 '20 at 16:29
  • That seems to be the case yeah – Lightness Races in Orbit Jan 15 '20 at 16:30
  • I am testing a scenario on g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) Two files static.h and static.cpp(static int variable, incr() func), create a static library "g++ -c static.cpp -o static.o && ar rcs static.a static.o" Two files library.h and library.cpp(incr call to static.a from incrDyn() ), a dynamic library "g++ -shared -fPIC -o libdyn.so lib.cpp". In main.cpp, I call incr() of static.a as well as incrDyn() func of libdyn.so. I compile using "g++ -o main main.cpp -L. -ldyn -lstatic". I run "main", the same static variable copy is incremented. @lightness-races-by-sa-3-0 – jainsuyogj Jan 15 '20 at 18:52
  • the command "g++ -shared -fPIC -o libdyn.so lib.cpp" does not have the static library name mentioned, but .so is still formed. I do specify it at the time of exe creation, but then would it mean only single copy is created of the static library? @alteredinstance – jainsuyogj Jan 15 '20 at 18:55
  • As per your answer there will be two copies which doesn't seem like? – jainsuyogj Jan 16 '20 at 06:35
  • @jainsuyogj I'm not super familiar with linux compilation, although I can say that while only one copy of the static library will be created (when the *.lib is compiled*), the .dll and the .exe *both* will contain their own copy of the .lib upon *their* compilation. So, when the program is run, any global variables from the static library will exist twice - in both the .exe. and the .dll's data. You wouldnt be able to see the two copies unless you decompiled both the .exe and .dll; upon which you'd see that both files contain a copy of the functions and objects linked from the static lib. – alteredinstance Jan 16 '20 at 15:39
  • So if I directly call an increment by 1 function of static library directly from *.exe, first copy will get increment by 1, and if I call a function of dll which internally call static lib increment function, will the second copy get incremented by 1? (Sorry if I am stating the obvious) – jainsuyogj Jan 16 '20 at 15:52
  • @jainsuyogj No need to apologize - You are completely correct, the function calls from the .exe will affect the static object within the .exe, and the same will happen for the functions/objects in the .dll. At runtime, the .exe and .dll will share address space, but they will still operate independently of each other. The .exe cannot see the static object inside the .dll and vice versa - they can each only see and manipulate *their own copy* of the static object. – alteredinstance Jan 16 '20 at 16:06