Preventing "static initialization order fiasco" in OpenBlas

[gjongren]

I am using OpenBLAS 0.2.14 compiled for dynamic dispatch based on CPU type. When initializing a C++ vector container (that under the hood uses openblas for copying elements) as a global/static variable I ran into the well-known "static initialization order fiasco". The problem was that the function
void CONSTRUCTOR gotoblas_init(void) in file memory.c was called AFTER the initialization of my vector, instead of before. This resulted in segmentation violation since the gotoblas pointer is not initialized before the underlying call to openblas via the vector container is made.

What I did to fix this was to change change the definition of CONSTRUCTOR in memory.c to

define CONSTRUCTOR attribute ((constructor (101)))

i.e., giving it a priority. According to the discussion on
http://stackoverflow.com/questions/11106875/attribute-constructor-call-order-confusion
this should make sure the gotoblas_init function is run before all other static initializations without constructor attribute, thus avoiding the problem.

It would be great if this issue could be fixed for future versions of openblas, as not being able to use openblas functionality in static/global variables is a serious problem..

[xianyi]

Thank you for your feedback and patch. I will merge it on develop branch.

[gjongren]

Excellent! :-)
By the way, I forgot to mention that I also changed the DESTRUCTOR define to
#define DESTRUCTOR attribute ((destructor (101)))
so that it is runs the last.