Windows mingw - libwinpthread-1.dll

[MSP-Greg]

Re the recent failures in Windows mingw builds, it's related to changes in libwinpthread, which is included in the 'bundled' dll files.

Ruby 3.4 shows that date_core.so is not loading libwinpthread.

Ruby 3.3 shows that its included date_core.so is not loading libwinpthread.

If one installs 3.4.1 on Ruby 3.3, it shows that date_core.so is loading libwinpthread. Using the bundled file, it fails with 'The specified procedure could not be found'. If one updates the bundled dll file, it loads fine.

So, given that mingw build tools provide standard tools and packages, and also a 'posix/*unix' emulation layer, I'm guessing that recently more functions were added. I assume this is also why ruby head has had commits like ruby/ruby#13304, which contains 'Detect clock_gettime and clock_getres for winpthreads'...

Lastly, @ntkme and I are rewriting the code that provides Windows build tools for setup-ruby, and I suspect we'll downgrade the packages related to libwinpthread for older Ruby versions (along with downgrading to gcc 14).

[ntkme]

Did a bit more digging and this might have to do with whatever RPATH equivalent is on windows (the DLL search path):
oneclick/rubyinstaller2-packages#25 (comment)

date_core.so isn't using the same DLL search path as the ruby binary, and this also leads to unexpected failure when msys2 is not installed that date_core.so won't be able to find libwinpthread-1.dll at all

[ntkme]

I found this: https://github.com/ruby/setup-ruby-pkgs/blob/main/Ruby_and_Windows.md

All builds from 2.4 and later use a Windows specific mechanism for finding dll's (known simply as 'manifest'). The dlls are located in bin/ruby_builtin_dlls. The manifest places them first in the 'lookup resolution'. Hence, testing against a specific dll version requires adjustments.

I think one problem is that ruby executable itself is using its manifest, but date gem shipped as part of ruby distribution is not using that. This can render date gem fail in a slightly different way - that it simply cannot find libwinpthread-1.dll if msys2 is not installed, instead of finding a wrong version.

@MSP-Greg I have no idea how this manifest work and maybe you will have some better idea here?

[MSP-Greg]

Note: started this before your last post, got distracted...

@ntkme Let me check that. x64 Windows builds use a Windows specific assembly manifest (xml) for dll path location.

I don't know how arm64 works.

date_core.so isn't using the same DLL search path as the ruby binary

I think that's incorrect. One might say that MSYS2 tools are unaware of the Ruby dlls when compiling.

First of all, I'm going to build Ruby master with my current (and up-to-date) MSYS2. Or, gcc-15 and the most recent 'git' package releases. Then, I'll install date, rename the MSYS2 libwinpthread-1.dll dll, and see if date loads.

[ntkme]

Output of strace ruby -r date -e exit

x64: https://github.com/ntkme/setup-msys2-gcc/actions/runs/15032813617/job/42249237714#step:14:63

--- Process 1580 loaded D:\rubyinstaller-head-x64\lib\ruby\gems\3.5.0+0\gems\date-3.4.1\lib\date_core.so at 00007ffbd0dc0000
--- Process 1580 loaded D:\a\_temp\msys64\ucrt64\bin\libwinpthread-1.dll at 00007ffbd0da0000

arm64: https://github.com/ntkme/setup-msys2-gcc/actions/runs/15032813617/job/42249237717#step:14:64

--- Process 8748 loaded C:\rubyinstaller-head-arm\lib\ruby\gems\3.5.0+0\gems\date-3.4.1\lib\date_core.so at 00007ffe63150000
--- Process 8748 loaded C:\a\_temp\msys64\clangarm64\bin\libwinpthread-1.dll at 00007ffe68a00000

They behave the same "incorrect" way as far as I can tell.

My guess would be that manifest only applies to direct DLL dependencies (whatever ldd $(which ruby) will show), and if anything is dynamically loaded later after startup, the manifest is not applied, and the dynamically loaded DLL may need its own manifest declared?

[larskanis]

Windows loader trace shows:

4024:33c0 @ 01714421 - LdrpCallTlsInitializers - INFO: Calling TLS callback 00007FF8D5DA60E0 for DLL "C:\Ruby35-arm\bin\aarch64-ucrt-ruby350.dll" at 00007FF8D5A90000
[...]
4024:2164 @ 01714875 - LdrpNameToOrdinal - WARNING: Procedure "clock_gettime" could not be located in DLL at base 0x00007FF8D5A90000.
4024:2164 @ 01714875 - LdrpReportError - ERROR: Locating export "clock_gettime" for DLL "C:\Ruby35-arm\lib\ruby\gems\3.5.0+0\gems\date-3.4.1\lib\date_core.so" failed with status: 0xc0000139.
(4024.2164): Unknown exception - code c0000139 (first chance)
4024:2164 @ 01714875 - LdrpGenericExceptionFilter - ERROR: Function LdrpSnapModule raised exception 0xc0000139
	Exception record: .exr 000000D64A1FC250
	Context record: .cxr 000000D64A1FBEA0
4024:2164 @ 01714875 - LdrpProcessWork - ERROR: Unable to load DLL: "C:\Ruby35-arm\lib\ruby\gems\3.5.0+0\gems\date-3.4.1\lib\date_core.so", Parent Module: "(null)", Status: 0xc0000139

So it is searching for clock_gettime in aarch64-ucrt-ruby350.dll instead of libwinpthread-1.dll.

This is similary to what objdump shows:

$ objdump -p C:/Ruby35-arm/lib/ruby/gems/3.5.0+0/gems/date-3.4.1/lib/date_core.so

C:/Ruby35-arm/lib/ruby/gems/3.5.0+0/gems/date-3.4.1/lib/date_core.so:   file format coff-arm64
[...]

The Import Tables:
  lookup 00034228 time 00000000 fwd 00000000 name 00035730 addr 00034770

    DLL Name: aarch64-ucrt-ruby350.dll
    Hint/Ord  Name
           0  Sleep
           0  clock_gettime
           0  gmtime_r
           0  localtime_r
           0  rb_alloc_tmp_buffer_with_count
           0  rb_ary_freeze
           0  rb_ary_new_capa
           0  rb_ary_new_from_args
[...]

Objdump doesn't show libwinpthread-1.dll as a dependency of date_core.so.

I didn't look into the ruby/date sources. So no idea why the wrong DLL is referenced for clock_gettime.

UPDATE:

The file C:/Ruby35-arm/lib/ruby/gems/3.5.0+0/gems/date-3.4.1/lib/date_core.so was just a leftover from the previous installation, when libwinpthread-1.dll wasn't necessary yet. gem uninst date && gem install date solved it.

[larskanis]

When ruby/date is build per rake compile the DLL dependencies of date_core.so are correct and the file can be loaded successfully:

$ objdump -p lib\3.4.4\aarch64-mingw-ucrt\date_core.so

lib\3.4.4\aarch64-mingw-ucrt\date_core.so:      file format coff-arm64
[...]

The Import Tables:
  lookup 00033270 time 00000000 fwd 00000000 name 0003478c addr 000337c0

    DLL Name: libwinpthread-1.dll
    Hint/Ord  Name
           0  clock_gettime64

  lookup 00033280 time 00000000 fwd 00000000 name 000347a0 addr 000337d0

    DLL Name: aarch64-ucrt-ruby340.dll
    Hint/Ord  Name
           0  Sleep
           0  gmtime_r
           0  localtime_r
           0  rb_alloc_tmp_buffer_with_count
           0  rb_ary_freeze
           0  rb_ary_new_capa

So only the build within the ruby/ruby tree is affected, but not the build of this separate repository.

[MSP-Greg]

I don't have an Arm64 system.

My guess would be that manifest only applies to direct DLL dependencies (whatever ldd $(which ruby) will show), and if anything is dynamically loaded later after startup, the manifest is not applied, and the dynamically loaded DLL may need its own manifest declared?

I just built:

ruby 3.5.0dev (2025-05-15T11:32:08Z master ed632cd0ba) +PRISM [x64-mingw-ucrt]
RbConfig::CONFIG["CC_VERSION_MESSAGE"] = "x86_64-w64-mingw32-cc.exe (Rev4, Built by MSYS2 project) 15.1.0 (just first line)

Obviously, my MSYS2 has gcc-15, it also has the 'r723' set of packages

I installed date, renamed the libwinpthread-1.dll file in msys64/ucrt64/bin, and the installed date loaded. objdump shows it needing libwinpthread-1.dll. Just to confirm, $LOADED_FEATURES shows date_core.so is the gem version, not the std-lib version.

So, the manifest applies to ext gems.

EDIT:

Same behavior with ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x64-mingw-ucrt]

[larskanis]

I updated the comment above. The file without reference to libwinpthread-1.dll was just a leftover from a gem install some weeks ago.

My guess would be that manifest only applies to direct DLL dependencies (whatever ldd $(which ruby) will show), and if anything is dynamically loaded later after startup, the manifest is not applied, and the dynamically loaded DLL may need its own manifest declared?

Exactly. This is what I did in in oneclick/rubyinstaller2@6f53127 . Unfortunately it doesn't work, since loading the libwinpthread-1.dll twice into the process leads to failed assertions in libyaml and a full stop.

Unfortunately the SXS manifest thing is not very flexible. It can only reference DLLs in the same directory. Not something in ..\..\bin\ruby_builtin_dlls\libxyz.dll or the like. So I don't have an idea how to solve this right now.

[MSP-Greg]

@larskanis

I am seeing .gem/ruby/3.4.0/gems/date-3.4.1/lib/date_core.so loading fine. What am I missing?

[ntkme]

@larskanis Can you please add line 25 back? I think the main ruby binary needs libwinpthread-1.dll, without this definition the main ruby executable cannot start without msys2 in path.

oneclick/rubyinstaller2@6f53127#diff-2440cbe82637e724b390bcb91fac81cc74714a4477764634d32e29140865cdd0L25

[ntkme]

Unfortunately it doesn't work, since loading the libwinpthread-1.dll twice into the process leads to failed assertions in libyaml and a full stop.

How do I trigger the failed assertion? I tried require 'psych' and indeed loaded libwinpthread-1.dll twice but it seems to be fine.

@larskanis I think it will work if you just add line 25 as I mentioned above unless I'm missing something about the assertion.

See this workflow here: https://github.com/ntkme/test/actions/runs/15051686956/job/42307772010

In strace I see:

--- Process 7604 loaded C:\rubyinstaller-head-arm\bin\ruby_builtin_dlls\libwinpthread-1.dll at 00007ff9f1c10000

...

--- Process 7604 loaded C:\rubyinstaller-head-arm\lib\ruby\3.5.0+0\aarch64-mingw-ucrt\date_core.so at 00007ff9d9300000
--- Process 7604 loaded C:\rubyinstaller-head-arm\lib\ruby\3.5.0+0\aarch64-mingw-ucrt\libwinpthread-1.dll at 00007ff9d92e0000
--- Process 7604 loaded C:\rubyinstaller-head-arm\lib\ruby\3.5.0+0\aarch64-mingw-ucrt\psych.so at 00007ffa0aa40000
--- Process 7604 loaded C:\rubyinstaller-head-arm\lib\ruby\3.5.0+0\aarch64-mingw-ucrt\libyaml-0-2.dll at 00007ff9d92b0000

And it seems to be working?