Technically, this is a warning, but Cygwin enables -Werror, so it is
treated as an error:
../../../../winsup/cygwin/exceptions.cc: In member function ‘int
_cygtls::call_signal_handler()’:
../../../../winsup/cygwin/exceptions.cc:1720:33: error: ‘’ may
be used uninitialized in this function
On Tue, 4 Jun 2024, Pali Rohár wrote:
> > I'm really sorry about this issue. It was caused by me by starting using
> > all those F* macros in crt-aliases.def.in file and then also moving
> > DECORATED_EXPORT() macro into func.def.in. I spotted it just because
> > fastcall exports (in 4/4 change)
On Tue, 24 Oct 2023, Ozkan Sezer wrote:
> LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.
How does this play out with winstore apps using winstorecompat? It seems
that GetModuleHandle in winstorecompat always returns NULL, while
LoadLibrary ends up calling
On Sun, 29 Oct 2023, Martin Storsjö wrote:
> This was an accidentally pushed commit - I had generated files with a version
> of autotools that I had on my system, different from the one we'ce normally
> used. I reverted this accidentally pushed commit in
>
I was looking at the recent commits, and saw the following hunk in
f86c3e7bbd88d755bc8ab0f467b486bf475656a1
diff --git a/mingw-w64-crt/configure b/mingw-w64-crt/configure
index 68b4c63b2..4f1971a87 100755
--- a/mingw-w64-crt/configure
+++ b/mingw-w64-crt/configure
@@ -2062,7 +2062,9 @@ struct
Thanks for looking into this. I was kind of intimdated by all the macros
in intrin.h, whose meanings were not entirely clear. Like __MACHINEI, I
though maybe the "I" stood for "Intel" so anything in a __MACHINEI
shouldn't be defined on ARM.
On Mon, 31 Jul 2023, LIU Hao wrote:
> The declaration
Recently, a build of pycryptodome failed on MSYS2's CLANGARM64, due to a
compile error about __cpuidex not being declared. I know cpuid
is an x86 thing, and wouldn't expect it to be present on arm(64).
While investigating why this started failing, I found a few things (two of
which seem to be
On Thu, 4 May 2023, Kacvinsky, Tom wrote:
> I cloned the repo and built with mingw-w64 x86, but used __cdecl instead of
> __stdcall. The import library had the right name decoration for x86 (x64 does
> not have a leading underscore), but the DLL had the symbol exported exactly
> as was specified
I was recently dealing with a project that seems to have been creatd from
a Visual Studio project template. It includes a "targetver.h" file with
the following comments:
// Including SDKDDKVer.h defines the highest available Windows platform.
// If you wish to build your application for a
(apologies for not including any quoted context, my mail client was not
cooperating with trying to quote an attachment)
Does the lib32/mi.def differ from the lib-common/mi.def? If not, couldn't
the lib32 variant also be omitted?
___
Mingw-w64-public
On Sat, 24 Dec 2022, LIU Hao wrote:
> The only issue in this thread seems to be inside GNU lib because it relies on
> the default value. That's probably not good; however, given GNU lib users are
> less likely to be aware of this Windows-specific macro, maybe we can propose
> GNU lib should set a
On Fri, 23 Dec 2022, Roger Pack wrote:
> Ran into this.
> According to
> https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170
> "The preprocessor macros WINVER and _WIN32_WINNT specify the minimum
> operating system version your code supports."
>
> Anyway,
On Fri, 8 Apr 2022, Martin Storsjö wrote:
> This header doesn't include any other header, defining the types that it
> assumes to be available. Would it make sense to add an include of the headers
> that provide the essentials, or is it a case where it's known to strictly
> require including
Signed-off-by: Jeremy Drake
---
mingw-w64-headers/include/delayloadhandler.h | 46
1 file changed, 46 insertions(+)
create mode 100644 mingw-w64-headers/include/delayloadhandler.h
diff --git a/mingw-w64-headers/include/delayloadhandler.h
An alternative implementation of libdelayimp.a, which is a thin wrapper
around OS APIs present in Windows 8 and newer, and which is required to
be used in store apps that wish to delay load, in lieu of libdelayimp.a.
Signed-off-by: Jeremy Drake
---
mingw-w64-crt/Makefile.am | 17
Windows 8 introduced a new implementation of the delay loading mechanism,
this time implemented almost entirely in the OS. The 'glue' to hook this
new implementation up to the linker is provided in the Windows SDK as
dloadhelper.lib, and a somewhat incomplete header called
delayloadhelper.h is
On Wed, 6 Apr 2022, Jeremy Drake via Mingw-w64-public wrote:
> I was looking into adding the 'new' dloadhelper.lib (Windows 8+,
> required to be used for UWP apps) to mingw-w64.
> It seems what *should* be in libdelayimp.a is actually
> in libmingwex.a. Is this intentional? Will t
I was looking into adding the 'new' dloadhelper.lib (Windows 8+,
required to be used for UWP apps) to mingw-w64. I was looking at
Makefile.am to see how libdelayimp.a is built, and I noticed that there
doesn't seem to be any sources added to it. Indeed, ar p libdelayimp.a
shows no contents. It
On Tue, 29 Mar 2022, Jeremy Drake via Mingw-w64-public wrote:
> On Wed, 30 Mar 2022, LIU Hao wrote:
>
> > Does it make sense to use `__builtin_setjmp()` and `__builtin_longjmp()`
> > here?
> > I am not sure whether Clang supports these. On x86 they restore only the BP
>
On Wed, 30 Mar 2022, LIU Hao wrote:
> Does it make sense to use `__builtin_setjmp()` and `__builtin_longjmp()` here?
> I am not sure whether Clang supports these. On x86 they restore only the BP
> and SP registers (other caller-saved registers are not preserved) and do not
> unwind the stack, so
A discussion came up today on MSYS2 Discord about trying to build qemu for
Windows ARM64
(https://discord.com/channels/792780131906617355/794889490941476915/958319683902259250).
Apparently QEMU is trying to use setjmp/longjmp within
TCG-generated code, and that is failing on ARM64 with
Microsoft defines this to the same value on x64, ARM, and ARM64, so do
the same.
This constant is used by Cairo. See
https://github.com/msys2/MINGW-packages/issues/11053
Signed-off-by: Jeremy Drake
---
mingw-w64-headers/crt/float.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
and build import library for arm64.
Signed-off-by: Jeremy Drake
---
.../{libarm32 => lib-common}/fwpuclnt.def | 28 +++-
mingw-w64-crt/lib32/fwpuclnt.def | 149 +-
mingw-w64-crt/lib64/fwpuclnt.def | 146 -
On Wed, 9 Mar 2022, Jeremy Drake via Mingw-w64-public wrote:
> +WfpCloseDPConfigureHandle ; Check!!! forwards to NtClose in ntdll.dll
> (ordinal 262)
> +WfpRIOChannelClose ; Check!!! forwards to NtClose in ntdll.dll (ordinal 262)
I'm not sure what I am supposed to "check&qu
Signed-off-by: Jeremy Drake
---
mingw-w64-crt/Makefile.in | 51 ---
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/mingw-w64-crt/Makefile.in b/mingw-w64-crt/Makefile.in
index 3609a9e6b..b9a69d83f 100644
--- a/mingw-w64-crt/Makefile.in
+++
and build import library for arm64.
Signed-off-by: Jeremy Drake
---
.../{libarm32 => lib-common}/fwpuclnt.def | 28 +++-
mingw-w64-crt/lib32/fwpuclnt.def | 149 +-
mingw-w64-crt/lib64/fwpuclnt.def | 146 -
It turns out that "cargo" links with fwpuclnt, and efforts to get rust
working for aarch64-pc-windows-gnu have hit the lack of fwpuclnt.a for
arm64.
While hooking that up, updated the def files to versions generated by
gendef against Windows 11 versions of the DLL.
The second commit is the
On Sun, 20 Feb 2022, LIU Hao wrote:
> 在 2022-02-17 03:40, Jeremy Drake via Mingw-w64-public 写道:
> >
> > Is this assertion failure a sign of a bug in winpthreads, or a sign of a
> > bug in glib (such as releasing a lock that is not held, for instance)?
> >
> >
>
On ARM64, I got this assertion failure while building GTK3:
FAILED: examples/application5/exampleapp5 resources.h
"C:\msys64\clangarm64\bin/glib-compile-resources.EXE"
"../gtk/examples/application5/exampleapp.gresource.xml" "--sourcedir"
"../gtk/examples/application5/." "--sourcedir"
On Sat, 23 Oct 2021, Martin Storsjö wrote:
> On Thu, 8 Apr 2021, Martin Storsjö wrote:
>
> > I guess the least risky solution would be to enable the "__USE_MINGW_ACCESS"
> > codepath unconditionally if using UCRT - what do you think?
> >
> > (One could also consider to change the implementation
The attempt to use ntquery.def.in to #include query.def didn't work
correctly for lib32. For consistency, duplicate the version in
lib-common too.
Signed-off-by: Jeremy Drake
---
mingw-w64-crt/lib-common/ntquery.def| 17 +
mingw-w64-crt/lib-common/ntquery.def.in | 1 -
On Sat, 23 Oct 2021, Martin Storsjö wrote:
> On Fri, 22 Oct 2021, Jeremy Drake wrote:
> > Comparing libquery.a to libntquery.a shows the latter is missing the
> > stdcall decorations. Perhaps the #include trick didn't go so well, and
> > it'd be better to just copy the def file (at least for
On Fri, 22 Oct 2021, Martin Storsjö wrote:
> On Thu, 21 Oct 2021, Jeremy Drake via Mingw-w64-public wrote:
>
> > There was a version already present as libquery.a for a couple of
> > arches, but the Windows SDK provides identical libquery.a and
> > libntquery.a, and th
On Thu, 21 Oct 2021, Jeremy Drake via Mingw-w64-public wrote:
> I am helping on a pull request to get pywin32 added to msys2's
> MINGW-packages, and I am trying to get the things it uses added to
> mingw-w64 that are not already present.
>
> One of those things is `-lntquery`, an
I am helping on a pull request to get pywin32 added to msys2's
MINGW-packages, and I am trying to get the things it uses added to
mingw-w64 that are not already present.
One of those things is `-lntquery`, an import library for Query.dll. I
would appreciate some pointers on how to add it
Obtained from program that printed them out, linked to Windows SDK, and
then merging the output with the existing file. A few of the GUIDs in
ADSIid.h were undefined in ADSIid.Lib:
IID_IADsSchema
IID_IDirectoryAttrMgmt
IID_IDSAttrMgmt
IID_IDSObject
IID_IDSSearch
The GUIDs were obtained by:
On Sun, 10 Oct 2021, Jeremy Drake via Mingw-w64-public wrote:
> After a report[1], made a simple test program that references all extern
> GUIDs from adsiid.h, and tried to link it with -ladsiid.
>
> lld-link: error: undefined symbol: _LIBID_ADs
> lld-link: error: u
On Sun, 10 Oct 2021, Jeremy Drake via Mingw-w64-public wrote:
> After a report[1], made a simple test program that references all extern
> GUIDs from adsiid.h, and tried to link it with -ladsiid.
>
Forgot to include footnote with link;
[1]:
https://github.com/msys2/MINGW-packages/
After a report[1], made a simple test program that references all extern
GUIDs from adsiid.h, and tried to link it with -ladsiid.
lld-link: error: undefined symbol: _LIBID_ADs
lld-link: error: undefined symbol: _IID_IADsSchema
lld-link: error: undefined symbol: _IID_IADsSearch
lld-link: error:
On Thu, 7 Oct 2021, Martin Storsjö wrote:
> This can also happen if calling a function which is marked "DATA" in
> the def files as it's not meant to be called/used normally (because we
> provide a replacement in libmingwex or lib*crt* that we think should
> be used instead). If the function that
On Fri, 20 Aug 2021, Corinna Vinschen wrote:
> On Aug 20 15:46, Ozkan Sezer wrote:
> > Those members do not exist in win7 versions of ddk headers.
> > Are they added for newer windows versions support?
>
> The documentation doesn't mention that, but I guess they have
> been added in W10 or so.
I
On Tue, 17 Aug 2021, Martin Storsjö wrote:
> LGTM. Am I understanding correctly that the difference here isn't visible in
> the current use of the tool (i.e. there's no buggy behaviour to be observed
> yet, and there's no other bug that could be piled on top of this, relying on
> the incorrect
According to Microsoft docs and observation of real images, section
headers are 40 bytes, not 36.
Signed-off-by: Jeremy Drake
---
mingw-w64-tools/genpeimg/src/img.h| 2 +-
mingw-w64-tools/genpeimg/src/img_pe.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
I was just using genpeimg code to try to investigte the .idata section
(for investigating https://github.com/msys2/MINGW-packages/issues/9363),
and I noticed
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-tools/genpeimg/src/img_pe.c#l136
> pe->section_list_sz = ((size_t)
On Fri, 6 Aug 2021, Martin Storsjö wrote:
> As for the patch itself, it seems fine to me - I presume the code is written
> to match the surrounding coding conventions and all that (I didn't
> doublecheck).
I made an effort to, but I can't guarantee I caught everything. I don't
think I checked
This can be done either by number, or by name. Most names are from the
documentation for LINK.EXE's /SUBSYSTEM option, but a few were made up
based on the constants and documentation on MS's PE Format document.
---
I wasn't sure about using strcasecmp, but I grepped and gendef uses it
without a
Signed-off-by: Jeremy Drake
---
mingw-w64-tools/genpeimg/src/img_pe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-tools/genpeimg/src/img_pe.c
b/mingw-w64-tools/genpeimg/src/img_pe.c
index e7ecbcd5b..345fc4e44 100644
---
Added high-entropy-va and control-flow-guard flags.
Also fixed an apparent copy-paste error on posix subsystem, and added
numeric value to XBOX subsystem for consistency with the others.
Signed-off-by: Jeremy Drake
---
mingw-w64-tools/genpeimg/src/genpeimg.c | 12 +++-
I was recently looking for an open-source tool to change the subsystem of an
executable. I came across genpeimg, and it looks like this would be a
good addition to it. First, though, I wanted to get it updated with the
latest Windows changes: new DLL characteristcs flags, and new image
machine
On Wed, 4 Aug 2021, Martin Storsjö wrote:
> On Tue, 3 Aug 2021, Jeremy Drake wrote:
>
> > While debugging this, noticed ruby seems to make *extensive* use of
> > setjmp/longjmp. Originally it was trying to use __builtin_setjmp but that
> > was crashing around the setjmp call (maybe clang's
On Tue, 3 Aug 2021, Martin Storsjö wrote:
> On Mon, 2 Aug 2021, Jeremy Drake via Mingw-w64-public wrote:
>
> > Ruby was running into a crash calling longjmp on a jmp_buf obtained by
> > calling setjmp from a function that had previously called alloca. This
> > was
Ruby was running into a crash calling longjmp on a jmp_buf obtained by
calling setjmp from a function that had previously called alloca. This
was resulting in mingw_getsp returning the *current* SP rather than the
"frame address"/"base pointer" for the frame. This caused longjmp to
raise
On Mon, 2 Aug 2021, Dmitry Kozlyuk wrote:
> Hello,
>
> Does MinGW-w64 builds support native thread-local storage (TLS),
If by MinGW-w64 you mean GCC targeting MinGW-w64, then no. GCC only
supports emutls on MinGW-w64.
> that will work for both MinGW-w64 and clang at the same time
If you want
On Sat, 24 Jul 2021, Jeremy Drake via Mingw-w64-public wrote:
> On Sun, 25 Jul 2021, LIU Hao wrote:
>
> > Please try the attached patch.
>
> That patch manually applied to my install (as opposed to applying and
> rebuilding headers and crt) fixed the time test failures I w
On Sun, 25 Jul 2021, LIU Hao wrote:
> 在 2021-07-25 05:38, Jeremy Drake via Mingw-w64-public 写道:
> >
> > Any thoughts on this? Maybe this needs to be moved further down the file?
> > Or would that be too late for something else? I am concerned this might
> > be
On Mon, 19 Jul 2021, Jeremy Drake via Mingw-w64-public wrote:
> I am working on debugging time-related test failures in perl, when built
> with i686 clang against mingw-w64 configured for ucrt.
> https://github.com/msys2/MINGW-packages/issues/9178
>
> The first test I
On Mon, 19 Jul 2021, Jeremy Drake via Mingw-w64-public wrote:
> Also, this test turned up what appears to be a bug in the UCRT path:
> #include
> #include
>
> int main(int argc, char ** argv)
> {
> time_t t = 2147483647;
> printf("%zu\n", sizeo
On Mon, 19 Jul 2021, Jeremy Drake via Mingw-w64-public wrote:
> The next test I debugged was failure of utime. Apparently it's trying to
> call _utime64, but with the struct with 32-bit time_ts, and getting
> EINVAL.
I was struggling to figure out how utime was aliased to _utime6
> The first test I debugged showed that it appears that time_t is 32-bits,
> even though I expected it to be 64-bit due to _mingw.h having:
> #if defined (_WIN32) && !defined (_WIN64) && !defined
> (__MINGW_USE_VC2005_COMPAT) && !defined (_UCRT)
> #ifndef _USE_32BIT_TIME_T
> #define
I am working on debugging time-related test failures in perl, when built
with i686 clang against mingw-w64 configured for ucrt.
https://github.com/msys2/MINGW-packages/issues/9178
The first test I debugged showed that it appears that time_t is 32-bits,
even though I expected it to be 64-bit due
On Tue, 13 Jul 2021, Tempelaar E. (Erik) wrote:
> For this to work correctly the stack size was increased somewhere in the
> past; on Unix using setrlimit, in mingw32 with 'LDFLAGS +=
> -Wl,--stack,0x0200' (32MiB)
> I've seen the "processthreadsapi" and noticed that it has a 'dwStackSize'
Not only does gnulib key off of the definition of _IOERR to know whether
to use its UCRT definitions, but the constants are different between
MSVCRT and the (internal) constants in UCRT source.
It turns out that the constants _IOFBF _IOLBF and _IONBF are still
present in the UCRT headers (they
On Thu, 8 Apr 2021, Jeremy Drake via Mingw-w64-public wrote:
> It looks like gnulib would Do The Right Thing if _IOERR were not defined
> for UCRT. Could you do that?
I've confirmed that the following patch allows gnulib in libunistring to
build.
diff --git a/mingw-w64-headers/crt/std
On Thu, 8 Apr 2021, Jeremy Drake via Mingw-w64-public wrote:
> It looks like gnulib would Do The Right Thing if _IOERR were not defined
> for UCRT. Could you do that?
In fact, it looks as though the definitions of those constants are not the
same between msvcrt and ucrt. UCRT _IOERROR i
On Thu, 8 Apr 2021, Liu Hao wrote:
> I don't think it is a regression, because there is `MSVC` in the comment on
> that line, and if MSVC was used to compile that file (with UCRT), the same
> error will occur. It's probably better to add `#elif defined _UCRT` above that
> line, and define a
On Thu, 8 Apr 2021, Martin Storsjö wrote:
> Hi,
>
> Nitpicky sidetrack - doesn't this fail to build for you unless you include
> errno.h too?
No, it built without so much as a warning with clang and gcc for me.
___
Mingw-w64-public mailing list
Hello,
For a few months, I've been working around an issue building ncurses with
clang targeting UCRT (https://github.com/msys2/CLANG-packages/issues/4),
and recently the same issue had to be worked around for GCC targeting
UCRT. I finally got around to debugging it, and found that the call at
On Fri, 26 Mar 2021, Liu Hao wrote:
> 在 2021-03-26 20:19, Martin Storsjö 写道:
> > This matches the public UCRT headers - the struct only contains one
> > single placeholder member.
> >
> > Signed-off-by: Martin Storsjö
> > ---
> > mingw-w64-headers/crt/stdio.h | 4
> > 1 file changed, 4
I was advised to bring this issue here, but I am not sure that mingw-w64
is 'wrong' in this case.
Original issue is https://github.com/msys2/CLANG-packages/issues/21
When building python against UCRT, its configure script fails to find
mktime, resulting in the mktime function being absent from
On Sun, 17 Jan 2021, Martin Storsjö wrote:
> On Thu, 14 Jan 2021, Martin Storsjö wrote:
>
> > On Wed, 13 Jan 2021, Jeremy Drake wrote:
> >
> > > On Wed, 13 Jan 2021, Martin Storsjö wrote:
> > >
> > > > The pragmatic path forward in that case, I think, would to add a
> > > > configure
> > > >
On Sun, 17 Jan 2021, Martin Storsjö wrote:
> What about patching upstream gcc/libstdc++ to add an option for preferring to
> provide its own __cxa_thread_atexit even if the platform seems to have one?
> Ideally it'd default to enabled for mingw platforms.
>
> // Martin
>
Hopefully that would be
On Wed, 13 Jan 2021, Martin Storsjö wrote:
> The pragmatic path forward in that case, I think, would to add a configure
> option to mingw-w64-crt for optionally enabling the __cxa_thread_atexit
> function. So if that's omitted from mingw-w64-crt, a new build of libstdc++
> would include their
On Wed, 13 Jan 2021, Martin Storsjö wrote:
> I haven't spent a lot of more time on it unfortunately, but I think my
> concluding thoughts were that it seems hard to get to work properly in this
> particular setup: As long as there's callbacks for both emutls for the
> allocations, and for
I was trying to build libuv on aarch64-w64-mingw32, and ran into an issue
that MemoryBarrier was undefined, and tracing through the headers it does
in fact seem to only be defined for i386/x86_64/ia64. Is it supposed to
be defined on arm/aarch64?
___
On Fri, 18 Dec 2020, Jeremy Drake via Mingw-w64-public wrote:
> Have there been any further ideas on this? I am concerned the current
> state of affairs, accessing freed memory during tls destruction of objects
> in the .exe module, could cause crashes in objects more complicated than
On Wed, 11 Nov 2020, Jeremy Drake wrote:
> On Wed, 11 Nov 2020, Martin Storsjö wrote:
>
> > Pushed patches 1-2 for now (that should be very benign and safe in any
> > case); patch 3 (changing how winpthreads clean up threads) is a bit more
> > risky, and the conclusion of this discussion was a
On Wed, 11 Nov 2020, Martin Storsjö wrote:
> Pushed patches 1-2 for now (that should be very benign and safe in any
> case); patch 3 (changing how winpthreads clean up threads) is a bit more
> risky, and the conclusion of this discussion was a bit fuzzy, but I can
> push that one as well if
On Thu, 29 Oct 2020, Liu Hao wrote:
> As far as I can tell it is only required by the c++ standard that
> thread_local objects are destroyed in the reverse order that they have
> been constructed and prior to any static destructor, and with Jeremy's
> patch it is guaranteed I think. The others
On Wed, 28 Oct 2020, Martin Storsjö wrote:
> Don't run the destructors directly after executing the user thread
> function. This allows running other TLS callbacks (e.g. tls_atexit.c)
> before running destructors registered via pthread_key_create (which
> can be used by the libgcc emutls
On Wed, 28 Oct 2020, Martin Storsjö wrote:
> Don't run the destructors directly after executing the user thread
> function. This allows running other TLS callbacks (e.g. tls_atexit.c)
> before running destructors registered via pthread_key_create (which
> can be used by the libgcc emutls
On Wed, 28 Oct 2020, Liu Hao wrote:
> The first sentence of your commit message was 'the TLS callback function for
> DLL_THREAD_DETACH is called after emutls has already cleaned up for the
> thread'. As it is clearly a bug, a more appropriate solution would be to make
> 'the TLS callback
On Wed, 28 Oct 2020, Liu Hao wrote:
> I would like to put this patch on hold for a while because of two reasons:
I agree that the destructor behavior is wrong at process exit, but it was
before this patch too. I believe this change is necessary for the thread
local destructors to be called at
The TLS callback function for DLL_THREAD_DETACH is called after emutls
has already cleaned up for the thread, so the tls_dtors were always NULL
at that time. Work around this by using Windows native TlsAlloc and
friends.
Fixes https://sourceforge.net/p/mingw-w64/bugs/859/
Signed-off-by: Jeremy
The TLS callback function for DLL_THREAD_DETACH is called after emutls has
already cleaned up for the thread, so the tls_dtors were always NULL at
that time. Work around this by using Windows native TlsAlloc and friends.
Fixes #859.
diff --git a/mingw-w64-crt/crt/tls_atexit.c
84 matches
Mail list logo
