ssp: prioritize stack guard init constructor

Other libraries might also be running constructors, which themselves are built with SSP enabled,
or are calling functions that are.
If those then get ordered befor the ssp constructor, they might crash due to the yet to be initialized
__stack_chk_guard.

This at least affects a statically linked glib, which launches a background thread in the
libgio constructor.
If the ssp constructor then runs at a random point after, it initializes the stack guard, and once
the thread returns from whatever function it's in, it crashes because the stack guard changed.

Signed-off-by: Timo Rothenpieler <timo.rothenpieler@uni-bremen.de>

mingw-w64-crt/ssp/stack_chk_guard.c

diff --git a/mingw-w64-crt/ssp/stack_chk_guard.c b/mingw-w64-crt/ssp/stack_chk_guard.c
index 499f003..adffb53 100644
--- a/mingw-w64-crt/ssp/stack_chk_guard.c
+++ b/mingw-w64-crt/ssp/stack_chk_guard.c
@@ -10,6 +10,11 @@
 
 uintptr_t __stack_chk_guard = 0;
 
+#if defined(__GNUC__) && __GNUC__ >= 9 && !defined(__clang__)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
+#endif
+
 #if defined __SSP__ || defined __SSP_STRONG__ || defined __SSP_ALL__
 // This function requires `no_stack_protector` because it changes the
 // value of `__stack_chk_guard`, causing stack checks to fail before
@@ -21,7 +26,7 @@
          -fstack-protector* options from CFLAGS.
 # endif
 #endif
-__attribute__((__constructor__))
+__attribute__((constructor(0)))
 static void __cdecl init(void)
 {
   unsigned int ui;
@@ -50,3 +55,7 @@
   __stack_chk_guard = 0xdeadbeef;
 #endif
 }
+
+#if defined(__GNUC__) && __GNUC__ >= 9 && !defined(__clang__)
+#pragma GCC diagnostic pop
+#endif