MSYS2 fails to run under Wine

[KrullBorg]

i'm sorry, but i didn't want to open an issue about that; i just wanted to open a discussion under sourceforge but i saw that it is no longer possible

so the problem is as the object: mintty doesn't start anymore under wine-staging after latest msys2 core updates; before updates it started but only with winxp compatibility setted

what could be the problem? thanks in advanced.

Click here to see the full error log

Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x610a569d).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:610a569d ESP:0064ca40 EBP:00000000 EFLAGS:00210257(  R- --  I  Z-A-P-C)
 EAX:00000000 EBX:612e99e4 ECX:00000001 EDX:00000001
 ESI:7ffdf000 EDI:7bc3edf0
Stack dump:
0x0064ca40:  7bc218c0 00000057 00000020 7bc7abb3
0x0064ca50:  612eafb0 00220290 00000014 6100358e
0x0064ca60:  00000007 00220000 00000001 00000001
0x0064ca70:  00000000 612e9748 612ea9a8 612e99e4
0x0064ca80:  612eafc2 00000000 0064cb18 610a5af3
0x0064ca90:  612e99e4 00000001 00000000 0064cae0
Backtrace:
=>0 0x610a569d in msys-2.0 (+0xa569d) (0x00000000)
  1 0x610a5af3 in msys-2.0 (+0xa5af2) (0x0064cb18)
  2 0x610a6116 in msys-2.0 (+0xa6115) (0x0064cbd8)
  3 0x61006c33 in msys-2.0 (+0x6c32) (0x0064cbd8)
  4 0x61005852 in msys-2.0 (+0x5851) (0x00000000)
  5 0x61005914 in msys-2.0 (+0x5913) (0x0064fe40)
  6 0x610069cf in msys-2.0 (+0x69ce) (0x0064fe40)
  7 0x00424740 in mintty (+0x2473f) (0x0064fe40)
  8 0x7b466142 call_process_entry+0x11() in kernel32 (0x0064fe58)
  9 0x7b467729 in kernel32 (+0x57728) (0x0064fea8)
  10 0x7bc8697c call_thread_func_wrapper+0xb() in ntdll (0x0064fed8)
  11 0x7bc89bed call_thread_func+0x7c() in ntdll (0x0064ffa8)
  12 0x7bc8695a RtlRaiseException+0x21() in ntdll (0x0064ffc8)
  13 0x7bc5895f in ntdll (+0x4895e) (0x0064ffe8)
  14 0xf75dc41d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000)
  15 0xf75dc4db wine_switch_to_stack+0x2a() in libwine.so.1 (0xff99c438)
  16 0x7bc5db2c LdrInitializeThunk+0x29b() in ntdll (0xff99c498)
  17 0x7b46e198 __wine_kernel_init+0x987() in kernel32 (0xff99d3b8)
  18 0x7bc5e09b __wine_process_init+0x18a() in ntdll (0xff99d448)
  19 0xf75da80a wine_init+0x299() in libwine.so.1 (0xff99d4a8)
  20 0x7c000bbb main+0x7a() in <wine-loader> (0xff99d8f8)
  21 0xf7406276 __libc_start_main+0xf5() in libc.so.6 (0x00000000)
0x610a569d: movzbl  0x1(%eax),%ecx
Modules:
Module  Address         Debug info  Name (99 modules)
PE    400000-  44e000   Export          mintty
PE  61000000-614f0000   Dwarf           msys-2.0
ELF 7b400000-7b7ec000   Dwarf           kernel32<elf>
  -PE  7b410000-7b7ec000   \               kernel32
ELF 7bc00000-7bcfc000   Dwarf           ntdll<elf>
  -PE  7bc10000-7bcfc000   \               ntdll
ELF 7c000000-7c004000   Dwarf           <wine-loader>
ELF 7d58d000-7d5a3000   Deferred        libgpg-error.so.0
ELF 7d5a3000-7d61c000   Deferred        libpcre.so.3
ELF 7d61c000-7d63a000   Deferred        libgcc_s.so.1
ELF 7d63a000-7d708000   Deferred        libgcrypt.so.20
ELF 7d708000-7d731000   Deferred        liblzma.so.5
ELF 7d731000-7d73a000   Deferred        librt.so.1
ELF 7d73a000-7d765000   Deferred        libselinux.so.1
ELF 7d765000-7d7f6000   Deferred        libsystemd.so.0
ELF 7d7f6000-7d7ff000   Deferred        libffi.so.6
ELF 7d7ff000-7d85b000   Deferred        libdbus-1.so.3
ELF 7d85b000-7d8e9000   Deferred        libgmp.so.10
ELF 7d8e9000-7d91f000   Deferred        libhogweed.so.4
ELF 7d91f000-7d95c000   Deferred        libnettle.so.6
ELF 7d95c000-7d971000   Deferred        libtasn1.so.6
ELF 7d971000-7d9a5000   Deferred        libidn.so.11
ELF 7d9a5000-7da06000   Deferred        libp11-kit.so.0
ELF 7da06000-7da1e000   Deferred        libresolv.so.2
ELF 7da1e000-7da23000   Deferred        libkeyutils.so.1
ELF 7da23000-7da30000   Deferred        libkrb5support.so.0
ELF 7da30000-7da35000   Deferred        libcom_err.so.2
ELF 7da35000-7da68000   Deferred        libk5crypto.so.3
ELF 7da68000-7db42000   Deferred        libkrb5.so.3
ELF 7db42000-7db56000   Deferred        libavahi-client.so.3
ELF 7db56000-7db65000   Deferred        libavahi-common.so.3
ELF 7db65000-7dcf1000   Deferred        libgnutls.so.30
ELF 7dcf1000-7dd44000   Deferred        libgssapi_krb5.so.2
ELF 7dd44000-7ddcd000   Deferred        libcups.so.2
ELF 7ddcd000-7de06000   Deferred        uxtheme<elf>
  -PE  7ddd0000-7de06000   \               uxtheme
ELF 7de06000-7de0d000   Deferred        libxfixes.so.3
ELF 7de0d000-7de19000   Deferred        libxcursor.so.1
ELF 7de27000-7de51000   Deferred        libexpat.so.1
ELF 7de51000-7de94000   Deferred        libfontconfig.so.1
ELF 7de94000-7dece000   Deferred        libpng16.so.16
ELF 7dece000-7deeb000   Deferred        libz.so.1
ELF 7deeb000-7df9f000   Deferred        libfreetype.so.6
ELF 7df9f000-7dfb2000   Deferred        libxi.so.6
ELF 7dfb2000-7dfb6000   Deferred        libxcomposite.so.1
ELF 7dfb6000-7dfc3000   Deferred        libxrandr.so.2
ELF 7dfc3000-7dfcf000   Deferred        libxrender.so.1
ELF 7dfcf000-7dfd6000   Deferred        libxxf86vm.so.1
ELF 7dfd6000-7dfda000   Deferred        libxinerama.so.1
ELF 7dfda000-7e000000   Deferred        libxcb.so.1
ELF 7e000000-7e152000   Deferred        libx11.so.6
ELF 7e152000-7e167000   Deferred        libxext.so.6
ELF 7e175000-7e20c000   Deferred        winex11<elf>
  -PE  7e180000-7e20c000   \               winex11
ELF 7e20c000-7e2c7000   Deferred        winmm<elf>
  -PE  7e210000-7e2c7000   \               winmm
ELF 7e2c7000-7e34d000   Deferred        rpcrt4<elf>
  -PE  7e2d0000-7e34d000   \               rpcrt4
ELF 7e34d000-7e494000   Deferred        ole32<elf>
  -PE  7e360000-7e494000   \               ole32
ELF 7e494000-7e4ba000   Deferred        imm32<elf>
  -PE  7e4a0000-7e4ba000   \               imm32
ELF 7e4ba000-7e4fd000   Deferred        winspool<elf>
  -PE  7e4c0000-7e4fd000   \               winspool
ELF 7e4fd000-7e578000   Deferred        shlwapi<elf>
  -PE  7e510000-7e578000   \               shlwapi
ELF 7e578000-7e845000   Deferred        shell32<elf>
  -PE  7e590000-7e845000   \               shell32
ELF 7e845000-7e936000   Deferred        comdlg32<elf>
  -PE  7e850000-7e936000   \               comdlg32
ELF 7e936000-7e950000   Deferred        version<elf>
  -PE  7e940000-7e950000   \               version
ELF 7e950000-7e9cc000   Deferred        advapi32<elf>
  -PE  7e960000-7e9cc000   \               advapi32
ELF 7e9cc000-7eb02000   Deferred        gdi32<elf>
  -PE  7e9e0000-7eb02000   \               gdi32
ELF 7eb02000-7ec63000   Deferred        user32<elf>
  -PE  7eb10000-7ec63000   \               user32
ELF 7ec63000-7ed6f000   Deferred        comctl32<elf>
  -PE  7ec70000-7ed6f000   \               comctl32
ELF 7ed91000-7eda4000   Deferred        libnss_files.so.2
ELF 7eda4000-7edb1000   Deferred        libnss_nis.so.2
ELF 7edb1000-7edcc000   Deferred        libnsl.so.1
ELF 7edcc000-7edd5000   Deferred        libnss_compat.so.2
ELF 7efab000-7f000000   Deferred        libm.so.6
ELF f734a000-f7386000   Deferred        ws2_32<elf>
  -PE  f7350000-f7386000   \               ws2_32
ELF f7386000-f73b0000   Deferred        iphlpapi<elf>
  -PE  f7390000-f73b0000   \               iphlpapi
ELF f73b0000-f73e0000   Deferred        netapi32<elf>
  -PE  f73c0000-f73e0000   \               netapi32
ELF f73e0000-f73e7000   Deferred        libxdmcp.so.6
ELF f73e9000-f73ee000   Deferred        libdl.so.2
ELF f73ee000-f75a5000   Dwarf           libc.so.6
ELF f75a5000-f75c2000   Deferred        libpthread.so.0
ELF f75c5000-f75c9000   Deferred        libxau.so.6
ELF f75d0000-f779c000   Dwarf           libwine.so.1
ELF f779f000-f77c4000   Deferred        ld-linux.so.2
ELF f77c6000-f77c7000   Deferred        [vdso].so
Threads:
process  tid      prio (all id:s are in hex)
0000000e services.exe
    00000022    0
    00000021    0
    00000019    0
    00000018    0
    00000016    0
    00000012    0
    0000000f    0
00000010 explorer.exe
    00000029    0
    00000028    0
    00000027    0
    00000011    0
00000014 winedevice.exe
    00000020    0
    0000001d    0
    0000001c    0
    0000001b    0
    0000001a    0
    00000015    0
0000001e plugplay.exe
    00000024    0
    00000023    0
    0000001f    0
00000025 (D) C:\msys32\usr\bin\mintty.exe
    0000002a    2
    00000026    0 <==

System information:
Wine build: wine-1.9.18 (Staging)
Platform: i386 (WOW64)
Version: Windows XP
Host system: Linux
Host version: 4.7.0-1-amd64

[mati865]

You could try compiling mintty 2.6.0 with new runtime version.
Another way to use MSYS2 inside Linux: https://github.com/Krakonos/msysww.

[KrullBorg]

how if mintty doesn't start? i also tried "wineconsole --backend=curses usr/bin/bash -l"

[mati865]

Run it from Linux console.

msysww --init
msysww -c

[KrullBorg]

if i understood "msysww -c" runs what i already tried (https://github.com/Krakonos/msysww/blob/master/msysww#L153); right?

[mati865]

-c runs default console (MSYS2).
Works nice for me on Arch with exception of 2 or 3 Wine bugs.

[KrullBorg]

but it runs the command https://github.com/Krakonos/msysww/blob/master/msysww#L153 or i didn't understand it? in the first case, as you can see on comment before, i already tried that command and it crashes

[ghost]

@KrullKorg what's your wine version? what's your msys2 runtime version?

Is it possible a Msys2 version later than or equal to 2.6.0?

corinna, would you be surprised if cygwin crashing on wine starts from this commit: ffcef702e78f81c64376dbe7547f242f67b433d4
Drop has_fast_cwd flag
crashing immediately at start
my bisect seems show that commit if i done it correctly
fracting, I wouldn't be surprised
unless you provide the new fast cwd method as Vista and laer
later
the old method up to XP/2K3 is not available anymore

[ghost]

Also take care about https://bugs.wine-staging.com/show_bug.cgi?id=682

[KrullBorg]

debian gnu/linux sid updated to last version (an lxc container inside debian gnu/linux sid updated to latest version)
libfreetype6 2.6.3-3+b1
wine-staging 1.9.18~sid
msys2 i don't know because mintty doesn't start, but i think it is the latest version

[ghost]

@KrullKorg

I think it is exact the problem I was discuss with corrina on irc. The latest msys2-runtime version is 2.6.0 after core-update, according to repo.msys2.org: http://repo.msys2.org/msys/i686/msys2-runtime-2.6.0-1-i686.pkg.tar.xz

The only way to workaround is, manually download old msys2-runtime version and manually revert /usr/bin/msys-2.0.dll

if it's hard to get Msys2 right on Wine for you, you can try https://hub.docker.com/r/teaci/msys64/ and https://hub.docker.com/r/teaci/msys32/ as the last chance, which are used by tea-ci.org
You can also try mirrors.tea-ci.org/msys2, which is used by Tea CI, maintain an outdated Msys2 mirror version, but keep compatibility with Wine.

Sorry I don't have time to continue join corrina to fix this soon until few months later, any one could give a hand would be great helpful...

`

[ghost]

<corinna>      the old method up to XP/2K3 is not available anymore
<fracting>     corinna, thanks, that explains. do you have a quick msdn link for vista fast cwd?
<corinna>      there is none
<corinna>      this is strictly internal to ntdll.dll
<corinna>      the onlydocs for that are inside Cygwin
<corinna>      the source code has lots of comments how this works
<corinna>      path.cc in the first place
<fracting>     ah, ok, nice
<corinna>      uh oh
<corinna>      that will be almost impossible to emulate
<fracting>     really? :/
<corinna>      take a very deep breath and have a look at find_fast_cwd_pointer()
<corinna>      but
<corinna>      hang on
<corinna>      that would mean Cygwin never worked in Vista emulation mode?
<corinna>      how do you run Cygwin in wine?
<fracting>     always XP mode in the past
<corinna>      in what OS emulation mode
<corinna>      that's the problem
<corinna>      so you never noticed this before
<corinna>      you really should run this in the latest emulation mode available
<corinna>      we can get it to work but it requires wine to provide a matching FAST_CWD struct based on the OS emulation mode

<jturney1>     shouldn't the cygwin DLL be marked with a minimum os version so it won't load on XP?
<corinna>      hmm, that will be tricky
<corinna>      jturney1, it uses entry points not available on XP now
<jturney1>     yeah
<corinna>      this isn't the problem
<jturney1>     but doesn't it get you a better error message?
<corinna>      the problem is that up to 2.5.1 it *did* run on XP so it has been tested in XP mode
<corinna>      but it would have never worked correctly in Vista or later emulation
<corinna>      but this has gone unnoticed
<corinna>      you know, this will be tricky to implement
<corinna>      it's an undocumented pointer to an undomcumented datastructure in ntdll.dll
<fracting>     very interesting
<corinna>      which even changed twice over the time
<corinna>      and Cygwin scans the code to find the pointer inside ntdll.dll
<corinna>      but there's practically no chance that you can generate the same assembler code as Visual C++
<fracting>     so even cygwin was harmed by the undocumented data structure?
<corinna>      yes
<fracting>     is that find_fast_cwd_pointer for performance improving, or no other way to implement at all?
<corinna>      we could have just given up and removed some POSIX features, but we didn't want to
<fracting>     what POSIX feature does it map to?
<corinna>      keep in mind that this is undocumented so the name FAST_CWD is an invention of the guy on the CYgwin ML  who tracked it down
<fracting>     ;)
<corinna>      it *seems* the idea of this change was to avoid potential crahes with multiple threads using and manipulating the CWD
<corinna>      while avoiding a global lock on the CWD
<corinna>      so what they did instead
<corinna>      Set/GetCurrentDirectory now don't use the CWD stored in PEB::ProcessParameters anymore

<corinna>      instead there's a new structure
<corinna>      what we call FAST_CWD
<corinna>      and a global (undocumented) pointer to the current FAST_CWD struct
<fracting>     very interesting XD
<corinna>      RtlGetCurrentDirectory_U fetches the current FAST_CWD pointer from the global pointer, incremens a use count
<corinna>      and reads the value
<fracting>     i need a deep breath as you said :)
<corinna>      RtlSetCurrentDirectory_U allocates a new FAST_CWD struct, fills it with life, and moves the global pointer to the new struct
<corinna>      then it checks if the use count of the old struct is 0, and, if so, deallocates it
<corinna>      the latter is also done by RtlGetCurrentDirectory_U, so the strcut disappears as soon as it has no user
<corinna>      Before we discuss this further
<fracting>     https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/path.c#L953
<corinna>      I would like to ask you to read the (really extensive) comments in path.cc, starting at line 3814
<fracting>     current wine emulates older windows like xp, right?
<corinna>      yup, that's the old technique
<corinna>      also, have a look at the strcut itself
<corinna>      grr
<corinna>      *struct*
<corinna>      it's defined in cygheap.h starting at line 204
<corinna>      I made sure to have lots and lots of comments
<corinna>      because it's the *only* documentation available
<fracting>     corinna, re L3814, you mean take care of copyright?
<corinna>      no
<corinna>      it's just the start of the code
<corinna>      yeah. it's the copyright comment
<corinna>      it's just the natural start for reading the code handling the CWD
<corinna>      just skip the copyright header
<fracting>     you mean start from fcwd_access_t::SetFSCharacteristics ?
<corinna>      never mind, maybe first have a look into cygheap.h to see how the struct looks like
<fracting>     yeah,
<fracting>     04 enum fcwd_version_t {
<fracting>     205   FCWD_OLD,
<fracting>     206   FCWD_W7,
<fracting>     207   FCWD_W8
<fracting>     208 };
<corinna>      as for the source in path.cc, it might be better to make sure you have tags and then start at cwdstuff::set and jump to the called functions to see what's going on
<fracting>     and more
<corinna>      I'm assuming you checkout out the sources with git and use an editor like vim or emacs
<jturney1>     or ed
<jturney1>     :)
<corinna>      right
<corinna>      not everybody wants to use these fancy editors
<fracting>     vim :)
<corinna>      good
<corinna>      read the comments
<corinna>      class fcwd_access_t is pretty easy to understand I hope
<fracting>     yep
<corinna>      *probably* we could remove the FAST_CWD_OLD type now, too
<corinna>      but
<corinna>      if somebody actually re-installs Vista or W7 from scratch, Cygwin would be broken as long as KB 2393802 hasn't been installed
<corinna>      so I rather keep it in for now

<fracting>     i see
<corinna>      fortunately there wasno change since W8
<Stromeko>     Don't tell M$, they change it if you ask nicely enough.
<corinna>      yuk
<corinna>      I dread every new OS version becasue of this code
<Stromeko>     ALso, if they do, it will be fun since all changes will be named W10. ;-)
<corinna>      haha
<corinna>      yselkowitz1, ping?
<fracting>     corinna, i feel that mircosoft makes your life very hard :)

<corinna>      fracting, I think we need some way to recognize running under wine from inside Cygwin
<corinna>      or
<corinna>      here's another idea
<corinna>      ok
<corinna>      I have an idea how to solve this...
<corinna>      but we cqan discuss this later
<fracting>     (example of detect wine: GetProcAddress("wine_get_version") https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/ntdll.spec#L1463 )
<corinna>      fracting, on second thought, there might be a better way
<fracting>     yes?:)
<corinna>      first, reimplement the new RtlGet/SetCurrentDirectory_U
<corinna>      it's not too tricky
<corinna>      second, export the global pointer pointing to this struct
<corinna>      e.g. a wine-specific function which returns the pointer
<corinna>      Cygwin could then call  GetProcAddress("wine_get_fast_cwd_ptr_func") and if that worked, just skip find_fast_cwd_pointer
<fracting>     i like this idea, but i believe this kinds of wine_get_fast_cwd_ptr_func wouldn't be accepted by wine upstream. however, in the worst case, i don't mind maintain a custom fork of wine with this extension, since i don't have any better idea as well
<corinna>      uhm
<corinna>      hmm
<corinna>      just looing into https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/path.c#L987
<corinna>      s/looing/looking/
<corinna>      is that identical to upstream?
<fracting>     it's the same version i'm using daily
<fracting>     since wine staging was accepted as part of official wine version, so it could be called as upstream as well. if you mean a traditional winehq version, let me check a while
<corinna>      I just wonder how the handle is treated
<fracting>     winehq version seems the same: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/path.c#l987
<corinna>      oh, hang on
<corinna>      the sharing flags are 0
<corinna>      so that's as in real windows
<corinna>      hmm
<corinna>      let me think about this for a bit, but we may end up reverting ffcef70 and use the old XP code in case we know we'er running on wine instead

<corinna>      hmm
<corinna>      just looing into https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/path.c#L987
<corinna>      s/looing/looking/
<corinna>      is that identical to upstream?
<fracting>     it's the same version i'm using daily
<fracting>     since wine staging was accepted as part of official wine version, so it could be called as upstream as well. if you mean a traditional winehq version, let me check a while
<corinna>      I just wonder how the handle is treated
<fracting>     winehq version seems the same: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/path.c#l987
<corinna>      oh, hang on
<corinna>      the sharing flags are 0
<corinna>      so that's as in real windows
<corinna>      hmm
<corinna>      let me think about this for a bit, but we may end up reverting ffcef70 and use the old XP code in case we know we'er running on wine instead
<yselkowitz>   is other xp code going to have to be reverted for wine too? :-S
<corinna>      no
<fracting>     re ffcef70, that seems also a good idea

[KrullBorg]

yes i downgraded msys2-runtime and mintty and it works

[andreygursky]

The same issue (wine-staging 1.9.18). Replacing msys-2.0.dll (from msys2-runtime-2.6.0-1-i686.pkg.tar.xz) with one from msys2-runtime-2.5.2-2-i686.pkg.tar.xz and mintty.exe (from mintty-12.5.0-1-i686.pkg.tar.xz) with one from mintty-12.4.2-1-i686.pkg.tar.xz workarounds the issue at the moment.

Despite of presence of msys-2.0.dbg, there is no source line info:

[...]
trace:dbghelp:SymMatchFileNameW (L"c:\\msys32\\usr\\bin\\msys-2.0.dbg" L"" (nil) (nil))
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dbg", but wrong timestamp
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dbg", but wrong size
trace:dbghelp:SymMatchFileNameW (L"c:\\msys32\\usr\\bin\\msys-2.0.dll" L"" (nil) (nil))
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dll", but wrong timestamp
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dll", but wrong size
[...]
fixme:advapi:LsaOpenPolicy ((null),0x6129dbe0,0x00000001,0x64c304) stub
fixme:advapi:LsaClose (0xcafe) stub
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x610a569d).
err:dbghelp:pe_load_msc_debug_info -Debug info stripped, but no .DBG file in module L"mintty"
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:610a569d ESP:0064ca30 EBP:00000000 EFLAGS:00210257(  R- --  I  Z-A-P-C)
 EAX:00000000 EBX:612e99e4 ECX:00000001 EDX:00000001
 ESI:7ffdf000 EDI:7bc3dc00
Stack dump:
0x0064ca30:  7bc22000 00000057 00000020 00000000
0x0064ca40:  00000007 00000030 00220024 00000026
0x0064ca50:  00000000 00220000 00000001 00000001
0x0064ca60:  00220024 00000000 0064cb08 612e99e4
0x0064ca70:  612eafc4 00000000 0064cb08 610a5af3
0x0064ca80:  612e99e4 00000001 00000000 0064cad0
Backtrace:
=>0 0x610a569d in msys-2.0 (+0xa569d) (0x00000000)
  1 0x610a5af3 in msys-2.0 (+0xa5af2) (0x0064cb08)
  2 0x610a6116 in msys-2.0 (+0xa6115) (0x0064cbc8)
  3 0x61006c33 in msys-2.0 (+0x6c32) (0x0064cbc8)
  4 0x61005852 in msys-2.0 (+0x5851) (0x00000000)
  5 0x61005914 in msys-2.0 (+0x5913) (0x0064fe30)
  6 0x610069cf in msys-2.0 (+0x69ce) (0x0064fe30)
  7 0x00424740 in mintty (+0x2473f) (0x0064fe30)
  8 0x7b45f582 call_process_entry+0x11() in kernel32 (0x0064fe48)
  9 0x7b460768 start_process+0x87(entry=<couldn't compute location>) [/build/source/dlls/kernel32/process.c:1122] in kernel32 (0x0064fe88)
  10 0x7bc7f87c call_thread_func_wrapper+0xb() in ntdll (0x0064feb8)
  11 0x7bc82681 call_thread_func+0xb0(entry=0x7b4606e0, arg=0x401000, frame=0x64ffb8) [/build/source/dlls/ntdll/signal_i386.c:2815] in ntdll (0x0064ff98)
  12 0x7bc7f85a RtlRaiseException+0x21() in ntdll (0x0064ffb8)
  13 0x7bc55706 start_process+0x35(kernel_start=0x7b4606e0) [/build/source/dlls/ntdll/loader.c:3430] in ntdll (0x0064ffe8)
  14 0xf75e337d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000)
  15 0xf75e34e0 wine_switch_to_stack+0x1f(func=0x7bc556d0, arg=0x7b4606e0, stack=0x650000) [/build/source/libs/wine/port.c:77] in libwine.so.1 (0xfff58a08)
  16 0x7bc5978e LdrInitializeThunk+0x24d(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/build/source/dlls/ntdll/loader.c:3492] in ntdll (0xfff58a68)
  17 0x7b466853 __wine_kernel_init+0x962() [/build/source/dlls/kernel32/process.c:1316] in kernel32 (0xfff59958)
  18 0x7bc5a63b __wine_process_init+0x15a() [/build/source/dlls/ntdll/loader.c:3701] in ntdll (0xfff599d8)
  19 0xf75e1743 wine_init+0x292(argc=0x5, argv=0xfff59f24, error="", error_size=0x400) [/build/source/libs/wine/loader.c:956] in libwine.so.1 (0xfff59a28)
  20 0x7c000c1a main+0x79(argc=<is not available>, argv=<is not available>) [/build/source/loader/main.c:367] in <wine-loader> (0xfff59e78)
  21 0xf73cd5f7 __libc_start_main+0xf6() in libc.so.6 (0x00000000)
0x610a569d: movzbl  0x1(%eax),%ecx
[...]

Is the msys-2.0.dbg for the msys-2.0.dll not properly created?

[ghost]

Hi @andreygursky , see https://bugs.wine-staging.com/show_bug.cgi?id=557 for the debugging symbol issue. It is a known issue that WineDbg does not know dwarf4, and it is a known issue that Win32 gdb does not understand Wine module, so I usually use a combination of WineDbg and Win32 gdb when debugging Msys2 on Wine, switching forth and back again and again, while sometimes rebuild Msys2 program with -gdwarf-2 -gstrict-dwarf like what Wine uses. It's a pain :) Any help is great appreciated!

[andreygursky]

@fracting, thanks for clarifying. BTW, the fact that cygwin dropped the support of WinXP seems to be very unfortunate. Do you know whether RedHat could reconsider that? Had they got substantial benefits from that turn? And where can I follow the progress on the workaround you discussed with Corinna (@github-cygwin?)?

Clear, dwarf4 should be better than dwarf2, but do many users of msys2 really make use of the improvements of the most recent dwarf standard or not really and compiling with dwarf2 could be enough?

[ghost]

@andreygursky sometimes we discuss in Cygwin mailing list [1], sometimes we discuss in Cygwin irc channel [2]. Unfortunately there is no log for irc. I can't answer your question on behalf of RedHat or Cygwin or corrina, but I think the decision has made and it wouldn't be changed since WinXP is lack of security updates.

[1] https://cygwin.com/lists.html
[2] https://cygwin.com/irc.html

[mati865]

Are you still having problems?
I'm still using updated msys2 64bit on Arch (wine staging, tested both 1.9.18 and 1.9.19) and had no problems:

mati865@Arch MSYS ~
$ pacman -Ss msys2-run
msys/msys2-runtime 2.6.0-1 (base) [installed]

[KrullBorg]

yes same problem, tried just now (debian sid, msys2 32bit, wine staging 1.9.22)

[andreygursky]

I've just asked about this on the cygwin mailing list. Let's see, what Cygwin developers say.

[andreygursky]

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

[github-cygwin]

On Nov 10 06:56, andreygursky wrote:

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

That's a bit unfair in terms of a summary. Here's what I wrote:

--- snip ---
Ending XP support was announced last year and only a year later we
actually dropped it. So we don't support Windows XP anymore, but we
would support Wine. However, the problem here is not on the Cygwin
side.

It seems Cygwin under Wine was not tested outside of XP compatibility
mode, or Wine doesn't support certain post-XP functions albeit claiming
Vista caompatibility. Cygwin doesn't require any functionality which
isn't available in Vista.
--- snap---

And, of course, we're not uncooperative, but that does not mean we can
easily revert XP compat. The entire code to support XP (and there was
lots of it) has been ripped out of Cygwin since 2.6. Reverting it isn't
the way to go. The right thing to do is to fix Wine. After all, Cygwin
still works nicely on all supported Windows systems and there's
apparently some lack in Wine in terms of Vista and later support.
Unfortunately I don't know what exactly the problem is, I'm not a Wine
expert.

Corinna

[KrullBorg]

ok winxp is dead. but if i set wine to "emulate" >= vista mintty doesn't start anyway

[andreygursky]

@github-cygwin,

If I understood you correctly, previously discussed changes in Cygwin
itself are not considered anymore and from now Wine is really left
alone with this issue?

[missing answer]

On Nov 10 06:56, andreygursky wrote:

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

That's a bit unfair in terms of a summary.

No answer I treated as no objection - that's why my summary. But now I'm very glad to hear from you that it is not the case :) So may we ask you relevant questions on some mailing list? Or only on IRC? The problem with later: it is hard to follow due to missing archives.

Unfortunately I don't know what exactly the problem is, I'm not a Wine expert.

Are there some WinAPI tests in Cygwin? Running them would easily reveal the missing or not properly implemented ones in Wine.

[github-cygwin]

On Nov 10 07:54, andreygursky wrote:

@github-cygwin,

If I understood you correctly, previously discussed changes in Cygwin
itself are not considered anymore and from now Wine is really left
alone with this issue?

[missing answer]

On Nov 10 06:56, andreygursky wrote:

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

That's a bit unfair in terms of a summary.

No answer I treated as no objection - that's why my summary. But now
I'm very glad to hear from you that it is not the case :) So may we
ask you relevant questions on some mailing list? Or only on IRC? The
problem with later: it is hard to follow due to missing archives.

You're free to discuss the issue on IRC freenode/#cygwin-developers and
the cygwin or cygwin-developer mailing lists. My time to work on Cygwin
got more limited lately so I'd prefer, time being the most limited
resource, to discuss this with developers who are actively going to
debug and fix the problem in Wine.

Unfortunately I don't know what exactly the problem is, I'm not a
Wine expert.

Are there some WinAPI tests in Cygwin? Running them would easily
reveal the missing or not properly implemented ones in Wine.

Sorry, no, but you can use native Linux strace and GDB on Wine to see
what's going on.

Corinna

[mati865]

When installing dash under Wine:

wine: Call from 0x7bc6151c to unimplemented function msys-2.0.dll.__locale_ctype_ptr, aborting

[andreygursky]

@fracting, I'm trying now to build msys2-runtime under wine-staging 2.0~rc5. It fails without any visible reason:

MSYS ~/msys2-runtime makepkg
...
make[4]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygserver'
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygthread.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygthread.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygtls.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygwait.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygwait.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygxdr.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygxdr.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o dcrt0.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/dcrt0.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o shared.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/shared.cc
ar rcv libgmon.a gmon.o mcount.o profil.o mcountFunc.o
a - gmon.o
a - mcount.o
a - profil.o
a - mcountFunc.o
ar cru libautomode.a automode.o
ar cru libbinmode.a binmode.o
ar cru libtextmode.a textmode.o
ar cru libtextreadmode.a textreadmode.o
Making version.cc and winver.o
Making version.cc and winver.o
2017-01-20 17:56
2017-01-20 17:56
Version 2.6.0
Version 2.6.0
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o version.o version.cc
g++ -B/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/libstdc++-v3/src/.libs -B/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/libstdc++-v3/libsupc++/.libs -L/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygwin -isystem /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/include -B/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/ -isystem /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/targ-include -isystem /home/andrey/msys2-runtime/src/msys2-runtime/newlib/libc/include    -pipe -O2 -g -ggdb \
-mno-use-libstdc-wrappers -L/usr/lib/w32api \
-Wl,--gc-sections -nostdlib -Wl,-Tcygwin.sc -static \
-Wl,--heap=0 -Wl,--out-implib,msysdll.a -shared -o msys0.dll \
-e _dll_entry@12 msys.def advapi32.o arc4random_stir.o assert.o autoload.o base64.o bsdlib.o ctype.o cxx.o cygheap.o cygthread.o cygtls.o cygwait.o cygxdr.o dcrt0.o debug.o devices.o dir.o dlfcn.o dll_init.o dtable.o environ.o errno.o exceptions.o exec.o external.o fcntl.o fenv.o fhandler.o fhandler_clipboard.o fhandler_console.o fhandler_dev.o fhandler_disk_file.o fhandler_dsp.o fhandler_fifo.o fhandler_floppy.o fhandler_mailslot.o fhandler_netdrive.o fhandler_nodevice.o fhandler_proc.o fhandler_process.o fhandler_procnet.o fhandler_procsys.o fhandler_procsysvipc.o fhandler_random.o fhandler_raw.o fhandler_registry.o fhandler_serial.o fhandler_socket.o fhandler_tape.o fhandler_termios.o fhandler_tty.o fhandler_virtual.o fhandler_windows.o fhandler_zero.o flock.o fnmatch.o fork.o fts.o ftw.o getopt.o glob.o glob_pattern_p.o globals.o grp.o heap.o hookapi.o inet_addr.o inet_network.o init.o ioctl.o ipc.o kernel32.o ldap.o libstdcxx_wrapper.o localtime.o lsearch.o malloc_wrapper.o minires-os-if.o minires.o miscfuncs.o mktemp.o mmap.o msg.o msys2_path_conv.o mount.o net.o netdb.o nfs.o nftw.o nlsfuncs.o ntea.o passwd.o path.o pinfo.o pipe.o poll.o posix_ipc.o pseudo-reloc.o pthread.o quotactl.o random.o regcomp.o regerror.o regexec.o regfree.o registry.o resource.o rexec.o rcmd.o scandir.o sched.o sec_acl.o sec_auth.o sec_helper.o sec_posixacl.o security.o select.o sem.o setlsapwd.o shared.o shm.o sigfe.o signal.o sigproc.o smallprint.o spawn.o strace.o strfmon.o strfuncs.o strptime.o strsep.o strsig.o sync.o syscalls.o sysconf.o syslog.o termios.o thread.o timer.o times.o tls_pbuf.o tty.o uinfo.o uname.o wait.o wincap.o window.o winf.o xsique.o  malloc.o acoshl.o acosl.o asinhl.o asinl.o atan2l.o atanhl.o atanl.o cabsl.o cacosl.o cargl.o casinl.o catanl.o cbrtl.o ccosl.o ceill.o cephes_emath.o cexpl.o cimagl.o clog10l.o clogl.o conjl.o copysignl.o coshl.o cosl.o cosl_internal.o cossin.o cpowl.o cprojl.o creall.o csinl.o csqrtl.o ctanl.o erfl.o exp10l.o exp2l.o expl.o expm1l.o fabsl.o fdiml.o finite.o floorl.o fmal.o fmaxl.o fminl.o fmodl.o frexpl.o ilogbl.o internal_logl.o isinf.o isnan.o ldexpl.o lgammal.o llrint.o llrintf.o llrintl.o llroundl.o log10l.o log1pl.o log2l.o logbl.o logl.o lrint.o lrintf.o lrintl.o lroundl.o modfl.o nanl.o nearbyint.o nearbyintf.o nearbyintl.o nextafterl.o nexttoward.o nexttowardf.o pow10l.o powil.o powl.o remainder.o remainderf.o remainderl.o remquol.o rint.o rintf.o rintl.o roundl.o scalbl.o scalbnl.o sinhl.o sinl.o sinl_internal.o sqrtl.o tanhl.o tanl.o tgammal.o truncl.o  version.o winver.o \
 /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygserver/libcygserver.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/libm/libm.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/libc/libc.a \
-lgcc /usr/lib/w32api/libkernel32.a /usr/lib/w32api/libntdll.a -Wl,-Map,msys.map
+ objcopy -R .gnu_debuglink_overlay --add-gnu-debuglink=/dev/null --only-keep-debug msys0.dll msys-2.0.dbg
+ objcopy -g --add-gnu-debuglink=msys-2.0.dbg msys0.dll
+ objcopy -R .gnu_debuglink_overlay --set-section-flag .gnu_debuglink=contents,readonly,debug,noload --change-section-address .gnu_debuglink=0x612e4000 msys0.dll
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/mkimport --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --replace=atexit= --replace=timezone= --replace=__xdrrec_getrec= --replace=__xdrrec_setnonblock= --replace=xdr_array= --replace=xdr_bool= --replace=xdr_bytes= --replace=xdr_char= --replace=xdr_double= --replace=xdr_enum= --replace=xdr_float= --replace=xdr_free= --replace=xdr_hyper= --replace=xdr_int= --replace=xdr_int16_t= --replace=xdr_int32_t= --replace=xdr_int64_t= --replace=xdr_int8_t= --replace=xdr_long= --replace=xdr_longlong_t= --replace=xdr_netobj= --replace=xdr_opaque= --replace=xdr_pointer= --replace=xdr_reference= --replace=xdr_short= --replace=xdr_sizeof= --replace=xdr_string= --replace=xdr_u_char= --replace=xdr_u_hyper= --replace=xdr_u_int= --replace=xdr_u_int16_t= --replace=xdr_u_int32_t= --replace=xdr_u_int64_t= --replace=xdr_u_int8_t= --replace=xdr_u_long= --replace=xdr_u_longlong_t= --replace=xdr_u_short= --replace=xdr_uint16_t= --replace=xdr_uint32_t= --replace=xdr_uint64_t= --replace=xdr_uint8_t= --replace=xdr_union= --replace=xdr_vector= --replace=xdr_void= --replace=xdr_wrapstring= --replace=xdrmem_create= --replace=xdrrec_create= --replace=xdrrec_endofrecord= --replace=xdrrec_eof= --replace=xdrrec_skiprecord= --replace=xdrstdio_create= --replace=acl=_acl32 --replace=aclcheck=_aclcheck32 --replace=aclfrommode=_aclfrommode32 --replace=aclfrompbits=_aclfrompbits32 --replace=aclfromtext=_aclfromtext32 --replace=aclsort=_aclsort32 --replace=acltomode=_acltomode32 --replace=acltopbits=_acltopbits32 --replace=acltotext=_acltotext32 --replace=chown=_chown32 --replace=facl=_facl32 --replace=fchown=_fchown32 --replace=fcntl=_fcntl64 --replace=fdopen=_fdopen64 --replace=fgetpos=_fgetpos64 --replace=fopen=_fopen64 --replace=freopen=_freopen64 --replace=fseeko=_fseeko64 --replace=fsetpos=_fsetpos64 --replace=fstat=_fstat64 --replace=ftello=_ftello64 --replace=ftruncate=_ftruncate64 --replace=getegid=_getegid32 --replace=geteuid=_geteuid32 --replace=getgid=_getgid32 --replace=getgrent=_getgrent32 --replace=getgrgid=_getgrgid32 --replace=getgrnam=_getgrnam32 --replace=getgroups=_getgroups32 --replace=getpwuid=_getpwuid32 --replace=getpwuid_r=_getpwuid_r32 --replace=getuid=_getuid32 --replace=initgroups=_initgroups32 --replace=lchown=_lchown32 --replace=lseek=_lseek64 --replace=lstat=_lstat64 --replace=mknod=_mknod32 --replace=mmap=_mmap64 --replace=open=_open64 --replace=setegid=_setegid32 --replace=seteuid=_seteuid32 --replace=setgid=_setgid32 --replace=setgroups=_setgroups32 --replace=setregid=_setregid32 --replace=setreuid=_setreuid32 --replace=setuid=_setuid32 --replace=stat=_stat64 --replace=tmpfile=_tmpfile64 --replace=truncate=_truncate64 libmsys-2.0.a msysdll.a _cygwin_crt0_common.o atexit.o cygwin_attach_dll.o cygwin_crt0.o dll_entry.o dll_main.o dso_handle.o libcmain.o premain0.o premain1.o premain2.o premain3.o pseudo-reloc-dummy.o
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a pthread.o thread.o libpthread.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a bsdlib.o libutil.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/libm/libm.a acoshl.o acosl.o asinhl.o asinl.o atan2l.o atanhl.o atanl.o cabsl.o cacosl.o cargl.o casinl.o catanl.o cbrtl.o ccosl.o ceill.o cephes_emath.o cexpl.o cimagl.o clog10l.o clogl.o conjl.o copysignl.o coshl.o cosl.o cosl_internal.o cossin.o cpowl.o cprojl.o creall.o csinl.o csqrtl.o ctanl.o erfl.o exp10l.o exp2l.o expl.o expm1l.o fabsl.o fdiml.o finite.o floorl.o fmal.o fmaxl.o fminl.o fmodl.o frexpl.o ilogbl.o internal_logl.o isinf.o isnan.o ldexpl.o lgammal.o llrint.o llrintf.o llrintl.o llroundl.o log10l.o log1pl.o log2l.o logbl.o logl.o lrint.o lrintf.o lrintl.o lroundl.o modfl.o nanl.o nearbyint.o nearbyintf.o nearbyintl.o nextafterl.o nexttoward.o nexttowardf.o pow10l.o powil.o powl.o remainder.o remainderf.o remainderl.o remquol.o rint.o rintf.o rintl.o roundl.o scalbl.o scalbnl.o sinhl.o sinl.o sinl_internal.o sqrtl.o tanhl.o tanl.o tgammal.o truncl.o libm.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a dlfcn.o libdl.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a minires.o libresolv.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a posix_ipc.o librt.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a sec_posixacl.o libacl.a
perl -p -e 'BEGIN{binmode(STDIN); binmode(STDOUT);}; s/msys-2.0/msys0/g' < libmsys-2.0.a > libmsys0.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygwin/libm.a libpthread.a libutil.a -v libc.a
make[3]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygwin'
make[2]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup'
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys'
make: *** [Makefile:883: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

MSYS ~/msys2-runtime

Any clue?

[andreygursky]

Aha, #421 (comment) solves the build failure. @Alexpux, can you build msys2-runtime with mingw-w64-cross-crt-clang-git?

[andreygursky]

@Alexpux, do you know, is it hard to not strip debuginfos from msys-2.0.dll into separate msys-2.0.dbg? I've rebuilt mintty with dwarf-2 debuginfos (which are not splitted by its simple Makefile) and backtraces are there.

[andreygursky]

OK, it was enough to comment out a line in winsup/cygwin/Makefile, where winsup/cygwin/dllfixdbg script is called:

# Rule to build msys-2.0.dll
$(TEST_DLL_NAME): $(LDSCRIPT) dllfixdbg $(DLL_OFILES) $(LIBSERVER) $(LIBC) $(LIBM) $(API_VER) Makefile $(VERSION_OFILES)
	$(CXX) $(CXXFLAGS) \
	-mno-use-libstdc-wrappers -L${WINDOWS_LIBDIR} \
	-Wl,--gc-sections $(nostdlib) -Wl,-T$(firstword $^) -static \
	-Wl,--heap=0 -Wl,--out-implib,msysdll.a -shared -o $@ \
	-e $(DLL_ENTRY) $(DEF_FILE) $(DLL_OFILES) $(VERSION_OFILES) \
	$(MALLOC_OBJ) $(LIBSERVER) $(LIBM) $(LIBC) \
	-lgcc $(DLL_IMPORTS) -Wl,-Map,msys.map
	#@$(word 2,$^) $(OBJDUMP) $(OBJCOPY) $@ ${patsubst %0.dll,%-2.0.dbg,$@} # <--- HERE
	@ln -f $@ new-$(DLL_NAME)

Now I have verbose backtrace.

[mgood7123]

ok i got something

tho pacman is slow af ;-;

71FD67799A2D+build@71fd67799a2d MSYS ~
$ pacman -S vim
resolving dependencies...
looking for conflicting packages...

Packages (1) vim-7.4.872-2

Total Download Size:    5.94 MiB
Total Installed Size:  37.90 MiB

:: Proceed with installation? [Y/n] n

71FD67799A2D+build@71fd67799a2d MSYS ~
$

# ubuntu 23.10 docker container
#     https://wiki.winehq.org/Ubuntu
sudo apt install winehq-staging winbind
winconfig # to install .wine folder

cd ~/.wine/drive_c

rm -rf msys*

#MSYS_VER=20150916 # works
#MSYS_VER=20160205 # works
#MSYS_VER=20160719 # works
#MSYS_VER=20160921 # works
#MSYS_VER=20161025 # works
#MSYS_VER=20180531 # broken, no window appears

wget http://mirrors.enigma-dev.org/distrib/x86_64/msys2-base-x86_64-${MSYS_VER}.tar.xz

tar -xf msys2-base-x86_64-${MSYS_VER}.tar.xz

cat <<EOF > msys64/etc/post-install/07-pacman-key.post
maybe_init_keyring ()
{
  if [ ! -d /etc/pacman.d/gnupg ]
  then
    /usr/bin/pacman-key --init
    /usr/bin/pacman-key --populate msys2 || true
    #/usr/bin/pacman-key --refresh-keys || true
    
    MAYBE_FIRST_START=true
  fi
}

maybe_init_keyring
EOF

export MSYSTEM=MSYS
export WINPTY_SHOW_CONSOLE=1

# the bat files execute but do not wait for the mintty processes to exit before they return

if [[ $MSYS_VER < 20160719 ]]
    then
        echo "type  wine msys64/msys2_shell.bat  then type it again once setup finishes"
    else
        # in 20160719 and higher
        #    msys2 provides msys2.exe
        #    wine is unable to execute msys2_shell.bat
        #        'Can't recognize ')' as an internal or external command, or batch script.'
        echo "type  wine msys64/msys2.exe  then type it again once setup finishes"
fi

[jhol]

which versions of msys2 + wine was last known to work together fully ?

Wine has never worked fully with Msys2. It's something that has been a work in progress for quite some time. I myself have been tinkering with this for 18-months, and have submitted quite a number of fixes and new features to Wine.

I maintain a small collection of fixes collected from various developers that I update from time to time:
https://gitlab.winehq.org/jhol/wine/-/commits/msys2-hacks-16

You should find fixes for most of the issues you are encountering there. We're at the point now where it works well enough to be usable much of the time, but there are still a large number of warnings and fixmes.

I am working on it in my day job so that it can be rolled out for a Jenkins build task that will run Msys2 on Wine in Docker in a K8s cluster. It is currently splutter into life.

if we attempt to execute bash we get the FAST_CWD crash

This is not actually a crash. The issue was tracked here: https://bugs.winehq.org/show_bug.cgi?id=40528, and was closed with "Not our bug".

The issue is that Msys2 and Cygwin have super-sketchy code that peeks into the private memory of the Windows DLLs to get the current working directory string more quickly. If this fails, it prints this noisy warning and then uses the conventional API to retrieve the string instead.

Wine can never replicate the private layout of Windows DLLs, so a proper solution would be to remove the FAST_CWD code path from Msys2/Cygwin, or at least remove the noisy warning.

and msys2_shell.cmd seems to show invalid character '(' when ran from wine console

This is tracked here: https://bugs.winehq.org/show_bug.cgi?id=53190

There is no fix available right now. The only solution is to avoid the script.

028c:fixme:sync:NtQueryDirectoryObject multiple entries not implemented

This is a manifestation of this bug: https://bugs.winehq.org/show_bug.cgi?id=52585

There is an active Merge Request from Jinoh Kang here: https://gitlab.winehq.org/wine/wine/-/merge_requests/4424

I'm hoping we will see this accepted quite soon.

@mgood7123 do you have any interest in joining this effort? It's quite a fun project. There are lots of opportunities for hacking and experimentation, especially given that we have all the source code.

[mgood7123]

I think this would be out of my scope especially for such a complex project, as much as i would like to

[jhol]

I think this would be out of my scope, as much as i would like to

Well there's lots of ways to be involved. Even just testing, experimenting and filing bugs is very beneficial.

[mgood7123]

I think this would be out of my scope, as much as i would like to

Well there's lots of ways to be involved. Even just testing, experimenting and filing bugs is very beneficial.

alright

[alexdelorenzo]

Wine can never replicate the private layout of Windows DLLs, so a proper solution would be to remove the FAST_CWD code path from Msys2/Cygwin, or at least remove the noisy warning.

Are you aware of any efforts on the Cygwin/Msys2 side to implement such a solution?

[TBBle]

I put together a trivial patch a while ago to do that, but I don't believe I ever submitted it upstream, as there were plenty of other issues I planned to look at, and never did. In fact, I posted the patch in this ticket (patches 0025 and 0026 in master...TBBle:MSYS2-packages:msys2-runtime-wine-cwd-support). I was working against MSYS2 because I've never tried to build Cygwin itself, and the MSYS2 packages build system let me easily throw patches in and build, so experimentation was rapid.

I haven't rebased that tree in over 5 years, so it's quite possible the patches no longer apply, but they should demonstrate how easy the change was, since we were just re-enabling a code-path that Cygwin had disabled but not removed when dropping pre-Windows7 support.

[mgood7123]

Imma try to use Github Actions CI to build with msys2 on windows runner

[jhol]

Update & Usage Instructions

As mentioned previously, I maintain a small collection of Wine patches which I update periodically. This is the current version:

• https://gitlab.winehq.org/jhol/wine/-/commits/msys2-hacks-16

The goal is to upstream as many of these fixes as possible over time.

With Wine built with 64-bit support with WoW support enabled, Msys2 is moderately usable.

To help others get started, here are some setup instructions.

Wine Installation

Dependencies

Check your Linux distribution for advice on how to build Wine from source. It can often be somewhat tricky to provide the source dependencies.

With Nix (either NixOS, or Nix installed into another Linux distro), with Nix Flake support enabled, entering a Wine development environment is very simple:

 $ nix develop 'nixpkgs/nixos-23.05#wine64'

Build

In the Wine source repository:

 $ mkdir _build
 $ cd _build
 $ ../configure --enable-win64 --prefix=/opt/wine-hacking
 $ make -j$(nproc)

Install

 $ sudo make install

Our patched version of Wine is now installed in /opt/wine-hacking. To use it, we must add it to the PATH of our shell environment:

 $ export PATH=$PATH:/opt/wine-hacking/bin

Note that /opt is not considered good choice as an installation location for Nix users, but it is convenient for debugging.

Msys2 Installation

First, prepare a Wine Prefix:

 $ export WINEPREFIX=$HOME/_wine/msys2

This will contain the Wine C-drive, and our Msys2 installation.

Msys2 Installation with the Installer

The installer, available from the Msys2 website is known to work with the patched version of Wine.

 $ wget https://github.com/msys2/msys2-installer/releases/download/2023-10-26/msys2-x86_64-20231026.exe
 $ wine msys2-x86_64-20231026.exe

The UI has a cosmetic issue running under Wine, but nonetheless competes the job.

The installer can also be operated in the terminal:

 $ wine msys2-x86_64-20220603.exe in com.msys2.root -t 'c:\msys64'

Msys2 Installation without the Installer

It is also possible to install Msys2 by simply unpacking the tar file:

 $ mkdir -p $WINEPREFIX/drive_c
 $ wget -q -O- "https://github.com/msys2/msys2-installer/releases/download/nightly-x86_64/msys2-base-x86_64-latest.tar.xz" | \
        tar -C "$WINEPREFIX/drive_c" -xJf -

Running Msys2 bash for the first time will trigger the post-install triggers, which results in an equivalent result to the GUI installer:

 $ wine64 c:/msys64/usr/bin/bash.exe --login -c echo

Usage

Typically users launch Msys2 through c:\msys64\msys2_shell.cmd, however, Wine is currently unable to execute this script due to a bug in the parser. We must therefore run Msys2 bash directly.

Running Msys2 bash in the terminal

Msys2 triggers many fixme, warning and error messages in Wine. These are useful for debugging purposes, but for usage, they can drown the terminal in messages.

You may wish to first disable the messages:

 $ export WINEDEBUG=-all

Now select which Msys2 environment to use:

• export MSYSTEM=MSYS (default)
• export MSYSTEM=MINGW32
• export MSYSTEM=MINGW64
• export MSYSTEM=UCRT64
• export MSYSTEM=CLANG32
• export MSYSTEM=CLANG64

Now we can launch the bash shell:

 $ wine64 c:/msys64/usr/bin/bash.exe --login

Running Msys2 bash in mintty

Alternatively, we can also run Msys2's GUI terminal emulator in Wine. In this case, it is not necessary to disable Wine debug messages.

 $ wine64 c:/msys64/usr/bin/mintty.exe /usr/bin/bash --login

Known Issues

Environment Variables

Wine passes most environment variables from the host system through to the guest process. This can cause problems for Msys2 processes which may react to the variables in unexpected ways.

Here is a non-exhaustive list of variables which may need to be unset:

  $ unset \
      CONFIG_SHELL \
      DISPLAY \
      EDITOR \
      LD_LIBRARY_PATH \
      QT_PLUGIN_PATH \
      SSL_CERT_FILE \
      TEMP \
      TEMPDIR \
      TMP \
      TMPDIR

Locale

Wine is sensitive to the host system locale when converting Windows UTF-16 strings to Linux strings. If the locale is not correctly configured, this can manifest in strange ways.

For example, the source code archive of OpenOCD contains files with Cyrillic characters. If the locale is not configured correctly, bsdtar -xf will fail unpack these files.

To ensure you have a correctly configured locale, run locale. If the output is as follows, the locale is set correctly.

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

If not, override it, with export LANG=en_US.UTF-8, and check the output of locale again.

Other UTF-8 locales may work correctly, but I have not tested these.

FAST_CWD

Msys2 (and Cygwin) currently use a dubious method to quickly acquire the current working directory string, by peeking at the private memory of the Windows DLLs. There is no way that this can be implemented in Wine, which triggers a noisy warning:

Cygwin WARNING:
  Couldn't compute FAST_CWD pointer.  This typically occurs if you're using
  an older Cygwin version on a newer Windows.  Please update to the latest
  available Cygwin version from https://cygwin.com/.  If the problem persists,
  please see https://cygwin.com/problems.html

This warning is safe to ignore because in this case, Msys2 will fall back to using the Windows API in the normal way.

The issue is tracked here in Wine, and was closed with "RESOLVED NOTOURBUG".

Incomplete Support in Wine

Wine's support for Msys2 and Cygwin is incomplete, and there are many unresolved bugs being tracked in the Wine bug tracker. Most of these can be found by searching for "msys2".

If you encounter any issue which has not been previously reported, please file a Wine bug.

[jhol]

Update: https://gitlab.winehq.org/jhol/wine/-/commits/msys2-hacks-17

• Rebase on wine-9.0-rc1
• Added a workaround for Wine bug 46070, 51813 "python fatal error redirecting stdout to file"

[1480c1]

small amusing note:

Seems pacman's output can get mangled if you run bash under wine

env.sh:

#!/usr/bin/bash

env -i "PATH=/opt/wine-hacking/bin:$PATH" \
    "WINEPREFIX=$HOME/_wine/msys2" \
    WINEDEBUG=-all \
    LANG=en_US.UTF-8 \
    LC_CTYPE="en_US.UTF-8" \
    LC_NUMERIC="en_US.UTF-8" \
    LC_TIME="en_US.UTF-8" \
    LC_COLLATE="en_US.UTF-8" \
    LC_MONETARY="en_US.UTF-8" \
    LC_MESSAGES="en_US.UTF-8" \
    LC_PAPER="en_US.UTF-8" \
    LC_NAME="en_US.UTF-8" \
    LC_ADDRESS="en_US.UTF-8" \
    LC_TELEPHONE="en_US.UTF-8" \
    LC_MEASUREMENT="en_US.UTF-8" \
    LC_IDENTIFICATION="en_US.UTF-8" \
    LC_ALL= \
    "$@"

[jhol]

Seems pacman's output can get mangled if you run bash under wine

Two possible workarounds for this:

• Run Msys2 pacman in Mintty GUI.
• Use pacman with the --noprogressbar flag.

[kovzol]

This is a really useful project, thanks, @jhol, for your wonderful work on this!
I have some minor issues and a major problem with the current version.
First, locking and removing /var/lib/pacman/db.lck seem problematic. If I want to install/upgrade packages, I usually have to remove it outside MSYS2 (in the host Linux system) manually, each time. Only after then I can run pacman -S .... Strangely enough, pacman -Sy ... does not always work, because of the same locking issue.
Also, I learned that the build systems I use (gcc or clang) take the wrong /usr/include/stdlib.h: the one from the host Linux system will be #included. This file should be invisible for MSYS2, or, at least, for the time of building something from source code. (I checked, via /z, Wine indeed makes this file visible, but I have no idea how to disable that for the session I want to build something from source.)

[kovzol]

Indeed, when removing $WINEPREFIX/dosdevices/z: (deleting the symlink to /), the correct /usr/include/stdlib.h will be #included.

[kovzol]

This type of removal is possible only after starting the MSYS session, during the session (from outside, in the Linux host).
In fact, in my case the real problem is that cmake adds the folder /usr/include to the Makefile (or in the ninja configuration) and gcc.exe (or clang.exe or g++.exe or clang++.exe) scans all possible volumes for the *.h files for inclusion. It seems that by design, all MingW variants look for all volumes when the path starts with /, so it seems to make more sense to add such inclusions just very carefully via the cmake config script, only with the exact volume names.

[kovzol]

I found that /usr/include was added by a buggy cmake module, so this should not be a general problem everywhere.

[kovzol]

Here is a blog entry with a tutorial on building a Windows application completely in Wine: https://matek.hu/zoltan/blog-20240822.php?t=d --- thanks, @jhol!

[eebssk1]

msys2-hacks-18 works fine too.

Update: commands do work but react very slow.

[kovzol]

It seems Gradle has difficulties with projects that require the Gradle daemon. There should be some file locking issue there. Any ideas to overcome this problem?

[Biswa96]

It seems Gradle has difficulties with projects that require the Gradle daemon

./gadlew --no-daemon ?

[eebssk1]

Anyone using msys2-hacks-18?

Everything(esp. gnu configuration scripts) runs as slow as hell.
Maybe I should give msys2-hacks-17 a try.

[eebssk1]

Anyone using msys2-hacks-18?

Everything(esp. gnu configuration scripts) runs as slow as hell. Maybe I should give msys2-hacks-17 a try.

turns out it's not wine's problem.
The container engine I use hooks proc access and it's not fast enough to proccess so much request made by wine.
(Though every process in msys2 still takes 1-3 secs to start up)

[kovzol]

It seems Gradle has difficulties with projects that require the Gradle daemon

./gadlew --no-daemon ?

It seems I cannot. The docs at https://docs.gradle.org/8.5/userguide/gradle_daemon.html#sec:disabling_the_daemon say that I should set GRADLE_OPTS to match org.gradle.jvmargs, otherwise a single-use daemon is invoked (which is still not working because of the missing file locking implementation in Wine). The meaning of this is not really explained, but I found some help at gradle/gradle#11517 (comment). Unfortunately, the way to find the "matching" GRADLE_OPTS still doesn't work, I either get an error message from Gradle like Improperly specified VM option 'MaxMetaspaceSize=384m -XX:+HeapDumpOnOutOfMemoryError -Xms256m -Xmx512m', or (when running via MSYS and not via cmd.exe) just no error message but Gradle still uses the daemon for a single run.

I also found https://discuss.gradle.org/t/need-help-trying-to-stop-daemon-and-re-use-launcher-jvm/47852 but that discussion seems unfinished.

I know this is not an MSYS2 issue but a problem in Wine with file locking, and maybe in Gradle too.

[Tereius]

I tried to get msys2 running in this docker image. I used this commit from the msys2-hacks-18 branch. The newest commit on that branch does not compile successfully.

My goal is to compile autotools-based projects (like openssl) for Windows in this Docker container. Unfortunately, it doesn't work because the bash.exe process hangs.

$ docker run -it ghcr.io/privatehive/conan-wine-msys2:latest starts the cmd within wine64. Everything works so far.
But as soon as bash is started, the process hangs indefinitely only showing the Cygwin warning:

[settings]
arch=x86_64
build_type=Release
os=Windows

Microsoft Windows 10.0.19043

Z:\home\conan>bash
Cygwin WARNING:
  Couldn't compute FAST_CWD pointer.  This typically occurs if you're using
  an older Cygwin version on a newer Windows.  Please update to the latest
  available Cygwin version from https://cygwin.com/.  If the problem persists,
  please see https://cygwin.com/problems.html

[jhol]

Jinoh Kang: server: Allow creating named pipes using \Device\NamedPipe\ as RootDirectory. is now merged!

[positron96]

Don't know why noone mentioned this, but there recently appeared an (experimental) docker image with wine and msys2, based on ubuntu debian: https://github.com/msys2/msys2-docker. To me it seems to be functional for the purposes of building stuff in CI/CD.

[jhol]

Interesting. @lazka is using msys2-hacks-18: https://github.com/msys2/msys2-docker/blob/main/build-base/Dockerfile#L15

[wsxarcher]

@jhol now that more stuff is merged into master what is the difference between msys2-hacks-18 and master now?