Re: [Hamlib-developer] Issue with latest pull and building WSJT-X 2.7.0 [ clock_gettime64 could not be located in the DLL ]

[George B. <geo...@gm...>]

I noticed 'Build_OS is mingw32' yet something is looking for a 64 bit 
routine. Is that OK?

On 5/19/25 8:59 AM, Nate Bargmann wrote:
> * On 2025 19 May 07:38 -0500, Hamlib Developer wrote:
>> Hi Folks,
>>
>> An issue has been encountered with Hamlib pulled from master as of UTC
>> 2025-05-18 @ 08:00:00 .
>>
>> The development environment is a fully clean and deployed JTSDK
>> 4.0.1u1 (see https://sourceforge.net/projects/hamlib-sdk/ ) and has
>> worked perfectly up until the time that Mike W9MDB became SK (and of
>> course he is therefore of no help to us now ☹)
>>
>> “Fully updated” means that the deployed MSYS2 environment is FULLY
>> updated with pacman -Syuu,
>>
>> LibUSB is the supplied 1.0.28 version that is known to work, and a
>> known-to-work Boost 1.88.0 environment has also been deployed with the
>> kit. The Qt environ is publicly-available Qt version being Qt 5.15.2.
>>
>> These are known facts:
>>
>>    *   Hamlib pulls the latest code from GIT, updates and compiles cleanly.
>>    *   WSJT-X pulls the latest code from GIT and compiles cleanly.
>>
>> But on execution of a freshly built WSJT-X 2.7.0 the following message
>> is displayed:
>>
>> The procedure entry point clock_gettime64 could not be located in the
>> dynamic link library c:\wsjt\wsjtx\bin\libhamlib4-dll
> I'm not familiar with the SDK or building WXJT-X, etc.  I can state that
> "clock_gettime64" is not found in the Hamlib repository as 'git grep
> clock_gettime64' returns nothing.
>
> I presume the issue exists outside of Hamlib.  Sorry.
>
> 73, Nate
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer