How to execute an auto-setup function - c++

Question

While working on a library depending on another third party library, I ran into the problem that the third party library is absolutely trash requires a manual call to a global setup and cleanup function.
int main()
{
setup();
//do stuff
cleanup();
}
Now, this is a total sh*t show not much of a problem in application code since it is just syntactically horrifying, but is actually a pain in a library.
The library is supposed to abstract these weird implementation details away, and requiring the user to call a setup function is like slapping my own face.
I tried to make them disappear
//namespace scope
struct AutoMagic
{
AutoMagic() {setup();}
~AutoMagic() {cleanup();}
};
AutoMagic automagic;
And then I realized this won't work across translation units as seen here and there
C++ global initialization order ignores dependencies?
Is initialization order guaranteed
C++ Dynamic initialization - across translation units
Initialization across c++ translation units
C++ static initialization order
Thus the question in the title.

Answer 1

You could try something like this:
std::shared_ptr<AutoMagic> init(){
static std::shared_ptr<AutoMagic> ptr(new AutoMagic{});
return ptr;
}
and in every translation unit do:
auto libMagic = init();
I didn't test it, but whichever translation unit calls init() first should create the object and whichever shared_ptr is unloaded last should call the destructor.

Answer 2

In the end, the only viable thing left is unportable compiler specific code
AutoMagic automagic __attribute__((init_priority(420));
Unportable as in, basically all mainstream compilers support this except msvc.
This attribute forces the variable to be initialized before all variables without this attribute and those with priority number greater than this variable.
This goes to illustrate that there is indeed a demand for initialization priority guarantees and that it is obviously still not being given by the standard.

Answer 3

Sadly, you can't really get out of this. You had a nice idea with the global instance, but indeed that doesn't work too well with dependencies. It has the further problem of potentially being optimised away by the linker unless you "use" it or are careful with build options; I encountered this issue with instances of an entity registration class inside my shared library.
Two solid options:
Add similar pieces of cr*p setup/teardown functions to your own library, that defer to setup() and cleanup()
Change libraries
I would apologise profusely, but really this is the third-party author's fault. So you should k*ll th*m get them to apologise.