Re: cygport upgrade to use gnupg2/gpg2 if available
On 25/06/2024 01:09, Brian Inglis via Cygwin-apps wrote: On 2024-06-24 16:23, Marco Atzeri via Cygwin-apps wrote: On 26/11/2023 15:40, Jon Turney via Cygwin-apps wrote: On 21/11/2023 06:58, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: But yeah, I think gpg2 obsoleting gpg, with compatibility symlinks is probably the right thing to do. I will implement this in the next 2.4.5 the current test version seems also able to correctly contact keyservers. That was a problem on latest gpg2 package Yay! At last. That has been frustrating as I have been tweaking my keyserver configs in the hopes of getting the latest keys accepted for my package sources, other downloads, and scripts. I might be able to update and willing to adopt libxslt if all our gpg updates hang together. test version for gnupg2-2.4.5-1 libksba-1.6.7-1 are also up. If you can also test Regards Marco
Re: cygport upgrade to use gnupg2/gpg2 if available
On 2024-06-24 16:23, Marco Atzeri via Cygwin-apps wrote: On 26/11/2023 15:40, Jon Turney via Cygwin-apps wrote: On 21/11/2023 06:58, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: After applying the attached patches, which add support for the newer gpg2 from gnupg2 if installed, the attached log second chunk shows the new keys verified by gpg2 added to lib/src_prep.cygpart ___gpg_verify(). Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for check and definition and __gpg_sign() for use in gpg signing of Cygwin patches and files. We should just switch to gpg2 an require that, there is no point in trying to use GPG 1.x anymore. https://repo.or.cz/cygport/rpm-style.git/commitdiff/84279e484726a68cc8f08e7c9126bef13d9510d7 I think this is the correct patch, so I'll probably apply this. But yeah, I think gpg2 obsoleting gpg, with compatibility symlinks is probably the right thing to do. I will implement this in the next 2.4.5 the current test version seems also able to correctly contact keyservers. That was a problem on latest gpg2 package Yay! At last. That has been frustrating as I have been tweaking my keyserver configs in the hopes of getting the latest keys accepted for my package sources, other downloads, and scripts. I might be able to update and willing to adopt libxslt if all our gpg updates hang together. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: Attn: libgpg-error maintainer
On 2024-06-24 14:52, Marco Atzeri via Cygwin-apps wrote:
On 24/06/2024 20:04, Brian Inglis via Cygwin-apps wrote:
On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote:
On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote:
On 23/06/2024 22:13, Marco Atzeri wrote:
On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote:
Update to current needed to update libgcrypt if you could please oblige?
unfortunately any recent version up to 1.50 are failing a lot of tests
PASS: t-version.exe
PASS: t-strerror.exe
fopen failed with bad code: 20
PASS: t-syserror.exe
FAIL: t-lock.exe
FAIL: t-printf.exe
FAIL: t-poll.exe
FAIL: t-b64.exe
FAIL: t-argparse.exe
FAIL: t-logging.exe
PASS: t-stringutils.exe
PASS: t-malloc.exe
===
6 of 11 tests failed
I was never able to find a solution, so if any one can look and give any
suggestion, I will appreciate
regards
Marco
I just rebuilt the old 1.37 and it is reporting the same errors,
while in 2020 it was passing all the tests
so it seems something else is playing a role here
very puzzling
Hi Marco,
I noticed that the build is generating libtool wrapper sources,
executables, and shell scripts under .../build/tests/.libs/ for the test
programs, so if that also happens with 1.37, that raises my suspicions that
what is failing is something to do with those wrappers and Cygwin libtool
mods.
Another possibility is that the failures are caused by a Cygwin bug
introduced since 2020. There have been several bugs in Cygwin 3.5.3 that
have been fixed. Since 3.5.4 hasn't been released yet, you could try the
latest test release of 3.6, which has all the bug fixes.
FWIW, I tried running t-lock.exe under strace and saw "SetThreadName:
SetThreadDescription() failed", followed quickly by a SIGSEGV. That again
suggests a possible Cygwin bug.
Thanks Ken,
Great suggestion - also did strace on t-printf from 1.50 tests/.libs with
src/.libs in the path to pick up test dll and got a loop due to a SEGV on
0005 - makes interesting reading, but does not mean much to me -
terminated it eventually.
Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized.
However, I see no changes since to SetThread related stuff since
misc_funcs.cc in 2022.
There may be some issues with Windows error or exception handling, so I will
retry under cygwin... 3.6.0-115...
No changes after upgrading all cygwin... packages to test 3.6.0-139...
including also taking the precaution of running:
$ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf
...
$ head /proc/version
CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64
(runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC
So perhaps the SetThreadDescription stuff needs another look?
Anyone familiar with that?
Ken, Brian,
it seems it was much simpler.
For some strange reason the HAVE_WEAK_SYMBOLS was defined.
Forcing it off
CYGCONF_ARGS="--disable-languages gl_cv_have_weak=no"
solved almost all errors
I just upload a 1.50 test version were the errors are down to 1
PASS: t-strerror.exe
fopen failed with bad code: 20
FAIL: t-syserror.exe
PASS: t-lock.exe
PASS: t-printf.exe
PASS: t-poll.exe
PASS: t-b64.exe
..
PASS: t-argparse.exe
PASS: t-logging.exe
PASS: t-stringutils.exe
PASS: t-malloc.exe
===
1 of 11 tests failed
let me know if libgcrypt can be built
Thanks Marco,
Great catch!
All tests pass for both libgpg-error 1.50 and libgcrypt: see attached logs.
I installed both locally and interactive tests of gpg{,v}{,2} all pass.
I fetched the latest Cygwin pubkey as I was getting warnings from my scripts,
and they are now all quiet.
So I am now dogfooding those two until your libgpg-error is officially updated,
then I can officially update my libgcrypt!
I made some tweaks to your libgpg-error cygport just in case something helped
with the issue.
I impertinently pushed some changes to your libgpg-error playground build to see
if there were any differences in there.
Please have a look at the manifest patch and cygport updates in the libgpg-error
playground branch and jobs.
My tweaked cygport seems to have passed there also; please see:
https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=libgpg-error
I have no idea what may have made the difference.
I updated the URIs, patched the manifest for W10, updated bld-req, added -cygwin
to config PACKAGE_VERSION, added reproducible build timestamp, commented out
test function override, added licence?
I am also adding -cygwin to config PACKAGE_VERSION and reproducible build
timestamp to libgcrypt (based on origsrc/.../ChangeLog as that seems consistent
across packages: whereas src ChangeLog and other files seem to be copied or
could be patched by us)!
--
Take care. Thanks, Brian Inglis Calga
Re: cygport upgrade to use gnupg2/gpg2 if available
On 26/11/2023 15:40, Jon Turney via Cygwin-apps wrote: On 21/11/2023 06:58, ASSI via Cygwin-apps wrote: Brian Inglis via Cygwin-apps writes: After applying the attached patches, which add support for the newer gpg2 from gnupg2 if installed, the attached log second chunk shows the new keys verified by gpg2 added to lib/src_prep.cygpart ___gpg_verify(). Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for check and definition and __gpg_sign() for use in gpg signing of Cygwin patches and files. We should just switch to gpg2 an require that, there is no point in trying to use GPG 1.x anymore. https://repo.or.cz/cygport/rpm-style.git/commitdiff/84279e484726a68cc8f08e7c9126bef13d9510d7 I think this is the correct patch, so I'll probably apply this. But yeah, I think gpg2 obsoleting gpg, with compatibility symlinks is probably the right thing to do. I will implement this in the next 2.4.5 the current test version seems also able to correctly contact keyservers. That was a problem on latest gpg2 package Regards Marco
Re: Attn: libgpg-error maintainer
On 24/06/2024 20:04, Brian Inglis via Cygwin-apps wrote: On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote: On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote: On 23/06/2024 22:13, Marco Atzeri wrote: On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote: Update to current needed to update libgcrypt if you could please oblige? unfortunately any recent version up to 1.50 are failing a lot of tests PASS: t-version.exe PASS: t-strerror.exe fopen failed with bad code: 20 PASS: t-syserror.exe FAIL: t-lock.exe FAIL: t-printf.exe FAIL: t-poll.exe FAIL: t-b64.exe FAIL: t-argparse.exe FAIL: t-logging.exe PASS: t-stringutils.exe PASS: t-malloc.exe === 6 of 11 tests failed I was never able to find a solution, so if any one can look and give any suggestion, I will appreciate regards Marco I just rebuilt the old 1.37 and it is reporting the same errors, while in 2020 it was passing all the tests so it seems something else is playing a role here very puzzling Hi Marco, I noticed that the build is generating libtool wrapper sources, executables, and shell scripts under .../build/tests/.libs/ for the test programs, so if that also happens with 1.37, that raises my suspicions that what is failing is something to do with those wrappers and Cygwin libtool mods. Another possibility is that the failures are caused by a Cygwin bug introduced since 2020. There have been several bugs in Cygwin 3.5.3 that have been fixed. Since 3.5.4 hasn't been released yet, you could try the latest test release of 3.6, which has all the bug fixes. FWIW, I tried running t-lock.exe under strace and saw "SetThreadName: SetThreadDescription() failed", followed quickly by a SIGSEGV. That again suggests a possible Cygwin bug. Thanks Ken, Great suggestion - also did strace on t-printf from 1.50 tests/.libs with src/.libs in the path to pick up test dll and got a loop due to a SEGV on 0005 - makes interesting reading, but does not mean much to me - terminated it eventually. Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized. However, I see no changes since to SetThread related stuff since misc_funcs.cc in 2022. There may be some issues with Windows error or exception handling, so I will retry under cygwin... 3.6.0-115... No changes after upgrading all cygwin... packages to test 3.6.0-139... including also taking the precaution of running: $ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf ... $ head /proc/version CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64 (runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC So perhaps the SetThreadDescription stuff needs another look? Anyone familiar with that? Ken, Brian, it seems it was much simpler. For some strange reason the HAVE_WEAK_SYMBOLS was defined. Forcing it off CYGCONF_ARGS="--disable-languages gl_cv_have_weak=no" solved almost all errors I just upload a 1.50 test version were the errors are down to 1 PASS: t-strerror.exe fopen failed with bad code: 20 FAIL: t-syserror.exe PASS: t-lock.exe PASS: t-printf.exe PASS: t-poll.exe PASS: t-b64.exe .. PASS: t-argparse.exe PASS: t-logging.exe PASS: t-stringutils.exe PASS: t-malloc.exe === 1 of 11 tests failed let me know if libgcrypt can be built Regards Marco
Re: libgpg-error allocation stack corruption
On 2024-06-24 12:04, Brian Inglis via Cygwin-apps wrote:
On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote:
On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote:
On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote:
On 23/06/2024 22:13, Marco Atzeri wrote:
On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote:
Update to current needed to update libgcrypt if you could please oblige?
unfortunately any recent version up to 1.50 are failing a lot of tests
PASS: t-version.exe
PASS: t-strerror.exe
fopen failed with bad code: 20
PASS: t-syserror.exe
FAIL: t-lock.exe
FAIL: t-printf.exe
FAIL: t-poll.exe
FAIL: t-b64.exe
FAIL: t-argparse.exe
FAIL: t-logging.exe
PASS: t-stringutils.exe
PASS: t-malloc.exe
===
6 of 11 tests failed
I was never able to find a solution, so if any one can look and give any
suggestion, I will appreciate
regards
Marco
I just rebuilt the old 1.37 and it is reporting the same errors,
while in 2020 it was passing all the tests
so it seems something else is playing a role here
very puzzling
Hi Marco,
I noticed that the build is generating libtool wrapper sources, executables,
and shell scripts under .../build/tests/.libs/ for the test programs, so if
that also happens with 1.37, that raises my suspicions that what is failing
is something to do with those wrappers and Cygwin libtool mods.
Another possibility is that the failures are caused by a Cygwin bug
introduced since 2020. There have been several bugs in Cygwin 3.5.3 that
have been fixed. Since 3.5.4 hasn't been released yet, you could try the
latest test release of 3.6, which has all the bug fixes.
FWIW, I tried running t-lock.exe under strace and saw "SetThreadName:
SetThreadDescription() failed", followed quickly by a SIGSEGV. That again
suggests a possible Cygwin bug.
Thanks Ken,
Great suggestion - also did strace on t-printf from 1.50 tests/.libs with
src/.libs in the path to pick up test dll and got a loop due to a SEGV on
0005 - makes interesting reading, but does not mean much to me -
terminated it eventually.
Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized.
However, I see no changes since to SetThread related stuff since misc_funcs.cc
in 2022.
There may be some issues with Windows error or exception handling, so I will
retry under cygwin... 3.6.0-115...
No changes after upgrading all cygwin... packages to test 3.6.0-139... including
also taking the precaution of running:
$ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf
...
$ head /proc/version
CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64
(runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC
So perhaps the SetThreadDescription stuff needs another look?
Anyone familiar with that?
I cut down various parts of the program, and finally narrowed it down to gpgrt
allocation or cygwin allocation corrupting the stack so return fails.
See attached gdb log.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéryone_test_x0 (format=format@entry=0x10040518e "%d %% %d") at stc-t-printf.c:101
101 if (one_test_rc1 == -1)
(gdb)
107 show (" sys: ->%s<-\n", one_test_buf1);
(gdb)
0x000100401087 in show (format=format@entry=0x10040505c " sys: ->%s<-\n")
at /usr/src/debug/libgpg-error-1.50-1/tests/t-common.h:119
119 /usr/src/debug/libgpg-error-1.50-1/tests/t-common.h: No such file or
directory.
(gdb)
122 in /usr/src/debug/libgpg-error-1.50-1/tests/t-common.h
(gdb)
run_tests () at stc-t-printf.c:201
201 one_test_2 ("%d %% %d", 17, 768114563);
(gdb)
0x00010040142d in one_test_x1 (format=format@entry=0x10040518e "%d %% %d")
at stc-t-printf.c:112
112 {
(gdb)
117 errno = ENOENT;
(gdb)
__errno () at
/usr/src/debug/cygwin-3.6.0-0.139.g7e3c833592b2/newlib/libc/errno/errno.c:17
17return &_REENT_ERRNO(_REENT);
(gdb)
__getreent () at
/usr/src/debug/cygwin-3.6.0-0.139.g7e3c833592b2/winsup/cygwin/include/cygwin/config.h:40
40__asm __volatile__ ("movq %%gs:8,%0" : "=r" (ret));
(gdb)
__errno () at
/usr/src/debug/cygwin-3.6.0-0.139.g7e3c833592b2/winsup/cygwin/include/cygwin/config.h:44
44return (struct _reent *) (ret - __CYGTLS_PADSIZE__);
(gdb)
one_test_x1 (format=format@entry=0x10040518e "%d %% %d") at stc-t-printf.c:118
118 va_start (arg_ptr, format);
(gdb)
119 rc2 = gpgrt_vasprintf (&buf2, format, arg_ptr);
(gdb)
gpgrt_vasprintf (r_buf=r_buf@entry=0x7caf0, format=format@entry=0x10040518e
"%d %% %d",
ap=ap@entry=0x7cb48 "\021") at
/usr/src/debug/
Re: Attn: libgpg-error maintainer
On 2024-06-24 11:14, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote: On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote: On 23/06/2024 22:13, Marco Atzeri wrote: On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote: Update to current needed to update libgcrypt if you could please oblige? unfortunately any recent version up to 1.50 are failing a lot of tests PASS: t-version.exe PASS: t-strerror.exe fopen failed with bad code: 20 PASS: t-syserror.exe FAIL: t-lock.exe FAIL: t-printf.exe FAIL: t-poll.exe FAIL: t-b64.exe FAIL: t-argparse.exe FAIL: t-logging.exe PASS: t-stringutils.exe PASS: t-malloc.exe === 6 of 11 tests failed I was never able to find a solution, so if any one can look and give any suggestion, I will appreciate regards Marco I just rebuilt the old 1.37 and it is reporting the same errors, while in 2020 it was passing all the tests so it seems something else is playing a role here very puzzling Hi Marco, I noticed that the build is generating libtool wrapper sources, executables, and shell scripts under .../build/tests/.libs/ for the test programs, so if that also happens with 1.37, that raises my suspicions that what is failing is something to do with those wrappers and Cygwin libtool mods. Another possibility is that the failures are caused by a Cygwin bug introduced since 2020. There have been several bugs in Cygwin 3.5.3 that have been fixed. Since 3.5.4 hasn't been released yet, you could try the latest test release of 3.6, which has all the bug fixes. FWIW, I tried running t-lock.exe under strace and saw "SetThreadName: SetThreadDescription() failed", followed quickly by a SIGSEGV. That again suggests a possible Cygwin bug. Thanks Ken, Great suggestion - also did strace on t-printf from 1.50 tests/.libs with src/.libs in the path to pick up test dll and got a loop due to a SEGV on 0005 - makes interesting reading, but does not mean much to me - terminated it eventually. Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized. However, I see no changes since to SetThread related stuff since misc_funcs.cc in 2022. There may be some issues with Windows error or exception handling, so I will retry under cygwin... 3.6.0-115... No changes after upgrading all cygwin... packages to test 3.6.0-139... including also taking the precaution of running: $ env -i PATH=build/src/.libs:/usr/bin:/bin:/sbin:/usr/sbin strace ./t-printf ... $ head /proc/version CYGWIN_NT-10.0-19045 version 3.6.0-0.139.g7e3c833592b2.x86_64 (runneradmin@fv-az534-931) (gcc version 11.4.0 (GCC) ) 2024-06-16 15:01 UTC So perhaps the SetThreadDescription stuff needs another look? Anyone familiar with that? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Re: Attn: libgpg-error maintainer
On 2024-06-23 20:37, Ken Brown via Cygwin-apps wrote: On 6/23/2024 7:46 PM, Brian Inglis via Cygwin-apps wrote: On 2024-06-23 15:46, Marco Atzeri via Cygwin-apps wrote: On 23/06/2024 22:13, Marco Atzeri wrote: On 22/06/2024 19:57, Brian Inglis via Cygwin-apps wrote: Update to current needed to update libgcrypt if you could please oblige? unfortunately any recent version up to 1.50 are failing a lot of tests PASS: t-version.exe PASS: t-strerror.exe fopen failed with bad code: 20 PASS: t-syserror.exe FAIL: t-lock.exe FAIL: t-printf.exe FAIL: t-poll.exe FAIL: t-b64.exe FAIL: t-argparse.exe FAIL: t-logging.exe PASS: t-stringutils.exe PASS: t-malloc.exe === 6 of 11 tests failed I was never able to find a solution, so if any one can look and give any suggestion, I will appreciate regards Marco I just rebuilt the old 1.37 and it is reporting the same errors, while in 2020 it was passing all the tests so it seems something else is playing a role here very puzzling Hi Marco, I noticed that the build is generating libtool wrapper sources, executables, and shell scripts under .../build/tests/.libs/ for the test programs, so if that also happens with 1.37, that raises my suspicions that what is failing is something to do with those wrappers and Cygwin libtool mods. Another possibility is that the failures are caused by a Cygwin bug introduced since 2020. There have been several bugs in Cygwin 3.5.3 that have been fixed. Since 3.5.4 hasn't been released yet, you could try the latest test release of 3.6, which has all the bug fixes. FWIW, I tried running t-lock.exe under strace and saw "SetThreadName: SetThreadDescription() failed", followed quickly by a SIGSEGV. That again suggests a possible Cygwin bug. Thanks Ken, Great suggestion - also did strace on t-printf from 1.50 tests/.libs with src/.libs in the path to pick up test dll and got a loop due to a SEGV on 0005 - makes interesting reading, but does not mean much to me - terminated it eventually. Attached log has been reduced by ~156MB and 2.5MLOC and lightly sanitized. However, I see no changes since to SetThread related stuff since misc_funcs.cc in 2022. There may be some issues with Windows error or exception handling, so I will retry under cygwin... 3.6.0-115... -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry --- Process 3172 created --- Process 3172 loaded C:/Windows/System32/ntdll.dll at 7ffb4b91 --- Process 3172 loaded C:/Windows/System32/kernel32.dll at 7ffb4b10 --- Process 3172 loaded C:/Windows/System32/KernelBase.dll at 7ffb490c --- Process 3172 thread 11960 created --- Process 3172 thread 2668 created --- Process 3172 loaded C:/.../cygwin64/usr/src/libgpg-error/libgpg-error-1.50-1.x86_64/build/src/.libs/cyggpg-error-0.dll at 00048825 --- Process 3172 thread 10200 created --- Process 3172 loaded C:/.../cygwin64/bin/cygwin1.dll at 7ffb34d2 --- Process 3172 loaded C:/.../cygwin64/bin/cygintl-8.dll at 0005ee2d --- Process 3172 loaded C:/.../cygwin64/bin/cygiconv-2.dll at 00038e6a 0 0 [main] t-printf (3172) ** 11071107 [main] t-printf (3172) Program name: C:/.../cygwin64/usr/src/libgpg-error/libgpg-error-1.50-1.x86_64/build/tests/.libs/t-printf.exe (windows pid 3172) 2761383 [main] t-printf (3172) OS version: Windows NT-10.0 3711754 [main] t-printf (3172) ** --- Process 3172 loaded C:/Windows/System32/advapi32.dll at 7ffb4b05 --- Process 3172 loaded C:/Windows/System32/msvcrt.dll at 7ffb4aa6 --- Process 3172 loaded C:/Windows/System32/sechost.dll at 7ffb4b7c --- Process 3172 loaded C:/Windows/System32/rpcrt4.dll at 7ffb4ad8 --- Process 3172 loaded C:/Windows/System32/bcrypt.dll at 7ffb4991 --- Process 3172 loaded C:/Windows/System32/cryptbase.dll at 7ffb4824 --- Process 3172 loaded C:/Windows/System32/bcryptprimitives.dll at 7ffb494c 13779 15533 [main] t-printf (3172) sigprocmask: 0 = sigprocmask (0, 0x0, 0x7FFB35004370) 22527 38060 [main] t-printf (3172) open_shared: name shared.5, shared 0x1A000 (wanted 0x1A000), h 0x128, m 0, created 0 725 38785 [main] t-printf (3172) user_heap_info::init: heap base 0xA, heap top 0xA, heap size 0x2000 (536870912) 432 39217 [main] t-printf (3172) open_shared: name S-1-5-21-3709023027-2347157756-1758867846-1001.1, shared 0x1A001 (wanted 0x1A001), h 0x124, m 1, created 0 212 39429 [main] t-printf (3172) user_info::create: opening user sha
