Hello, Martin Storsjö <[email protected]> wrote: > With the upcoming GCC 16, it should be possible to use the Windows native > TLS mechanism with GCC as well - but this is a choice that is made when > GCC is configured and built; the syntax used for declaring the variable as > thread local does not affect it.
Thanks for the information. I didn't know that GCC 16 will come with possible Windows native TLS mechanism. The issue here is how TLS (by C language) works on Windows, and there are multiple ways. IIUC, by changing the code to "__declspec(thread)", it becomes non-thread-local (equivalent to remove "__thread"), hence, the problem of linkage at runtime looks gone superficially. As long as an application is not multi-threaded or it doesn't care about FIPS certification, it's OK. It might be a workaround in some situations. I think that it is the decision of a user who builds libgcrypt with whatever compiler with whatever options, until compilers with TLS stabilized. In the current situation (where thread local strage implementations differ among compilrs+compiler-options), a user should be careful about consequences like dependency to runtime libraries. If really needed, I'm open to introduce new code for Windows, using Windows native TLS mechanism in fips.c. I believe that the situation is better for POSIX systems. -- _______________________________________________ Gcrypt-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
