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 
>>> 0000000500000000 - 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              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