MSYS2-packages
MSYS2-packages copied to clipboard
MSYS2 fails to run under Wine
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 possibile
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 advace
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
You could try compiling mintty 2.6.0 with new runtime version. Another way to use MSYS2 inside Linux: https://github.com/Krakonos/msysww.
how if mintty doesn't start? i also tried "wineconsole --backend=curses usr/bin/bash -l"
Run it from Linux console.
msysww --init
msysww -c
if i understood "msysww -c" runs what i already tried (https://github.com/Krakonos/msysww/blob/master/msysww#L153); right?
-c
runs default console (MSYS2).
Works nice for me on Arch with exception of 2 or 3 Wine bugs.
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
@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?
Also take care about https://bugs.wine-staging.com/show_bug.cgi?id=682
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
@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...
`
<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
yes i downgraded msys2-runtime and mintty and it works
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-1~2.5.0-1-i686.pkg.tar.xz) with one from mintty-1~2.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?
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!
@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?
@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
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]
yes same problem, tried just now (debian sid, msys2 32bit, wine staging 1.9.22)
I've just asked about this on the cygwin mailing list. Let's see, what Cygwin developers say.
Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(
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
ok winxp is dead. but if i set wine to "emulate" >= vista mintty doesn't start anyway
@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.
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
When installing dash under Wine:
wine: Call from 0x7bc6151c to unimplemented function msys-2.0.dll.__locale_ctype_ptr, aborting
@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?
Aha, https://github.com/Alexpux/MSYS2-packages/issues/421#issuecomment-199046874 solves the build failure. @Alexpux, can you build msys2-runtime with mingw-w64-cross-crt-clang-git?
@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.
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.
Stumbled across this problem today. FWIW, I think the matching wine bug is here: https://bugs.winehq.org/show_bug.cgi?id=40528