When linking statically, m4ri_build_all_codes() must be called or segfault ensues

[Former user]

Hey,

I had a bugreport in CryptoMiniSat by Axel Kemper:

"Before using m4ri, one has to call m4ri_build_all_codes() or m4ri_init(). If you are using m4ri as DLL, m4ri_init() is called automatically. But if you link statically, you are out of luck."

He is experiencing this when CryptoMiniSat using m4ri. I made the constructor of the class that uses m4ri to call m4ri_build_all_codes() so it "works" but this is a workaround I suspect? I'm not familiar with M4RI to this detail, but it would be nice to know what you think of this. Is this a bug? Or a somewhat obscure use-case?

Thanks for clearing this up!

PS: I think this only applies to Windows, as on Linux it works OK without the m4ri_build_all_codes(). By Windows I mean MSVC and a Windows build.

[Martin Albrecht]

The only reason for m4ri_init() is to call m4ri_build_all_codes() which generates the codes used in the "*_russian" functions. Calling m4ri_build_all_codes() directly has the same effect. Running it twice is okay.

Under Linux: m4ri_init() and m4ri_fini() are fun before and after main() respectively (cf. http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html)

Under Windows: I am surprised it worked with shared libraries under Windows. We have code for this (cf. misc.c) but I never test on Windows. I don't know of a way of running code before/after main() under Windows, so DllMain() had to suffice. Hence, it would make sense that if you link statically you have to call m4ri_init() and m4ri_fini() yourself.

[Martin Albrecht]

This is - for now - expected behaviour.