Static Variable Initialization Over a Library

Static variable initialization over a library

As a general rule of thumb, an application do not include static or global variables from a library unless they are implicitly or explicitly used by the application.

There are hundred different ways this can be refactored. One method could be to place the static variable inside function, and make sure the function is called.

Duplicate static variable initialization in C++

Thank you all for your answers.
As Todd said, I forgot to include the link command for MyLibraryTest. Here it is :

/usr/local/bin/g++  -O3 -DNDEBUG  -rdynamic CMakeFiles/MyLibraryTest.dir/MyLibraryTest.cpp.o  -o ../bin/MyLibraryTest -Wl,-rpath,/tmp/Build/MyLibraryTest/Release/bin: ../bin/libMyLibrary.so -ldl

The problem was related to the RPATH. If I do not use the -Wl,-rpath option any more, the test works fine !

I use CMake to build my projects, and found this :
https://cmake.org/Wiki/CMake_RPATH_handling. Now I use the following command in my CMakeLists.txt, which removes the -Wl,-rpath link option.

set (CMAKE_SKIP_RPATH ON)

C++ static variable in .lib does not initialize

I had a similar problem and solved it by setting the lib project as a dependency of the main app project and then setting 'Link Library Dependencies' and 'Use Library Dependency Inputs' to Yes for the main project.

---

Update:

Recently I discovered that Visual Studio 2015 now supports a /WHOLEARCHIVE linker flag. I can't find it through the linker options, but you can add it as an additional command line option. It works similar to the GCC flag -whole-archive and you add it to your target linker flags (not to the static lib flags).

For example, specify /WHOLEARCHIVE:lib_name as an additional linker command line option and it will include all symbols from that lib. You can do this more than one lib as well.

If you use this /WHOLEARCHIVE:lib_name you no longer need the 'Link Library Dependencies' and 'Use Library Dependency Inputs' set to Yes. This is perfect for solutions generated through CMAKE. See a related answer here: https://stackoverflow.com/a/42083877/1151329

Constructor of static variable inside shared library

So, it turns out that @Pupsik was completely right! Btw, thanks.

As he said, the library was being optimized out:

Maybe your MyLib.cpp was optimized out by the compiler since no references found to that library? Try to add some dummy function in the MyLib.cpp and call it from main.cpp

The code on github that I referenced didn't get optimized out because there was, indeed, a function inside that library being called by the main function.

The solution I found was the use of the linker flag -as-needed. It links the library no matter what, thus not being taken out of the binary.

So, that clears things out.
Thanks, again.

Static initialization in linked library under Windows C++

Is the "library file" part of the final executable. If it is an
object file in a statically linked library, it will only be part
of the final executable if it resolves an otherwise unresolved
external symbol. (This is the definition of a library.) If you
never use any symbol in the object file, it won't be part of
your executable, and it's as if the source file wasn't part of
the application.

If the library is dynamically loaded, the situation is slightly
different; a .dll is loaded as a unit (and not object file by
object file, so it's not really a library), but if there are no
unresolved symbols which would be resolved by loading the DLL,
it won't be loaded either.

What you probably want to do is link against the object files,
and not against a library. In Visual Studios, this means
putting all of the sources in the same project. Or... you can
link the library as a .dll, and then explicitly load it using
LoadLibrary. (This is what we do for libraries which are only
referenced because they have constructors of static objects
which register themselves.)

---

Related Topics