Re: [PATCH] w32: Use __declspec(thread) for FIPS thread context TLS

I have delved deeper into the issue and found that the it is caused by an
implicit runtime dependency when using __thread under MinGW.

The GNU implementation of __thread on Windows (or MinGW32) seems to
dynamically link to libwinpthread.dll and libgcc_s_seh-1.dll. Since these
dependencies are not guaranteed to be present on standard Windows systems,
the OS loader fails to load the main library. This is further confirmed
by the fact that static linking or manually deploying these runtime DLLs
resolves the issue.

The proposed change, which uses conditional compilation to replace
__thread with __declspec(thread) when __MINGW32__ is defined, provides
a viable solution. This approach is effective because __declspec(thread)
is a Windows-native API that leverages the OS's built-in TLS mechanism,
thereby eliminating the dependency on the aforementioned DLLs and ensuring
the library loads correctly on all Windows targets.

Thanks,
Knugi


Dec 9, 2025, 22:13 by [email protected]:

> On Tue,  9 Dec 2025 15:08, Werner Koch said:
>
>> How did you noticed that libgpg-error TLS was also not properly
>> intialized?
>>
>
> Sorry, I was in libgpg-error hacking mode and thus mixed this uop with
> the new code in Libgcrypt.  Anyway, if there is a problem we need to
> anaylyze the problem to see where both attribution methods differ.
>
> If we use thread-local-storage (TLS) in Libgcrypt we may want to
> delegate this to libgpg-error which is anyway a dependency.
>
>
> Salam-Shalom,
>
> Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>