Globals initialization order failure with opencv

[egorpugin]

See opencv/opencv#18166

[mloskot]

[gdal-dev] Exception in GDALAllRegister() thread seems related.

If you have a specific error report to GDAL, fill it in, otherwise this should be closed, I think.

[egorpugin]

Do you have an issue for that thread?
Anyways feel free to close as duplicate.

[mloskot]

Do you have an issue for that thread?

No. OP has never opened one providing us with his "empty" test application as reproducible minimal example, so we can "experience [similar] a crash in GDALAllRegister" as you can read in OP's posts.

The final report was:

Changing both to /MDd doesn't seem to make a difference - the same fatal exception occurs

which to me seems fishy as there are hundreds of such GDAL clients built on Windows in the wild,
including myself building and running GDAL clients (all built w/ /MD[d]) on daily/weekly basis for ~15 years
without observing such problem.
So, I suspect the problem was due to some build configuration/API misuse issue.

In case of static libraries (i.e. /MT[d]) situation may be different and prone to random static initialisation fiasco indeed, but we still need a Minimal Working Example with details on build configuration in order to reproduce the problem.

[egorpugin]

It's easy enough.
The issue is because of linking order. (Do not remember .obj files into .lib or even .lib files into .exe).
MSVC does not have specific init order. It's undefined. I saw such issues several times (qt - said wontfix, some other libs with globals).

Possible solution from my pov is to make wrapper auto f() {static x ...; return x;}. Tried this approach in my project (~2y ago), new issue is that it's hard to set destruction order correctly. I came to solution to maintain global library state or context with all globals moved into this structure or something similar. Works good.

[mloskot]

It's easy enough.
(...)
Possible solution from my pov is to make wrapper (...)

Feel free to submit PR with a fix in C++11.