http://bugs.winehq.org/show_bug.cgi?id=31429
Bug #: 31429 Summary: unimplemented function msvcrt.dll._stat64 and msvcrt.dll._fstat64 Product: Wine Version: 1.5.10 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs@winehq.org ReportedBy: htl10@users.sourceforge.net Classification: Unclassified
The latest version of R (http://www.r-project.org) is built with a slightly customized mingw-w64 to provide win32- and win64- multiarch binaries.
http://www.stats.bris.ac.uk/R/bin/windows/base/R-2.15.1-win.exe
The toolchain is inside: http://www.stats.bris.ac.uk/R/bin/windows/Rtools/Rtools215.exe
and described in http://www.stats.bris.ac.uk/R/bin/windows/Rtools/
Previous version of R (2.14.x) and the toolchain works okay under wine. But the latest complains of:
(R 2.15) wine: Call from 0x7ef79b28 to unimplemented function msvcrt.dll._fstat64, aborting fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 80000100
and running gcc --version inside wine cmd from the toolchain, complains of:
========================= wine: Call from 0x7ef79b28 to unimplemented function msvcrt.dll._stat64, aborting wine: Unimplemented function msvcrt.dll._stat64 called at address 0x7ef79b28 (thread 0026), starting debugger... Unhandled exception: unimplemented function msvcrt.dll._stat64 called in 32-bit code (0x7ef79b28). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ef79b28 ESP:0104fae8 EBP:0104fb4c EFLAGS:00000216( - -- I -A-P- ) EAX:0044a878 EBX:7efe4048 ECX:00000000 EDX:00000001 ESI:0104faf4 EDI:00000049 Stack dump: 0x0104fae8: 4d430001 0025ef28 00000090 80000100 0x0104faf8: 00000001 00000000 7ef79b28 00000002 0x0104fb08: 0044ad08 0044a878 00000000 00000000 0x0104fb18: 4d430000 0025efb8 00000008 00000000 0x0104fb28: 00000000 00000000 4d430003 00000000 0x0104fb38: 00000000 00000000 7ef79ada 0025ef28 Backtrace: =>0 0x7ef79b28 call_dll_entry_point+0x508() in ntdll (0x0104fb4c) 1 0x0024000f (0x0025ef28) 0x7ef79b28 call_dll_entry_point+0x508 in ntdll: leal 0xfffffffc(%esp),%esp .... ======================
It is possible that this is both a code change in R (to provide 64-bit file access on 32-bit platforms) as well as a change in the toolchain used from mingw-based to mingw-x64 based.
Can these two unimplemented functions be implemented quickly? It is possible such a problem will be more frequent sine it looks like mingw-w64 is gaining ground compared to mingw, for a variety of reasons.
http://bugs.winehq.org/show_bug.cgi?id=31429
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WORKSFORME
--- Comment #1 from Hin-Tak Leung htl10@users.sourceforge.net 2012-08-08 12:14:33 CDT --- Sorry for the noise - had winecfg or winetrick doing msvcrt native by default, and the native msvcrt was rather old (year 2000-ish).
278581 Mar 7 2000 ${HOME}/.wine/drive_c/windows/system32/msvcrt.dll
Realized my mistake when I looked at source under wine/dlls/msvcrt and found it implemented.
Removing the msvrt native override in winecfg confirms both of the issues as spurious.
http://bugs.winehq.org/show_bug.cgi?id=31429
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED Resolution|WORKSFORME |INVALID
--- Comment #2 from Austin English austinenglish@gmail.com 2012-08-09 12:09:07 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=31429
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #3 from Hin-Tak Leung htl10@users.sourceforge.net 2012-08-09 12:18:24 CDT --- (In reply to comment #2)
Closing.
What exactly is the rationale of fiddling with the status and a single word comment? I already reserved it as workedforme after realising it was a local mis-configuration which hasn't shown until now. I thought the issue was over.
http://bugs.winehq.org/show_bug.cgi?id=31429
--- Comment #4 from Austin English austinenglish@gmail.com 2012-08-09 12:19:58 CDT --- (In reply to comment #3)
(In reply to comment #2)
Closing.
What exactly is the rationale of fiddling with the status and a single word comment? I already reserved it as workedforme after realising it was a local mis-configuration which hasn't shown until now. I thought the issue was over.
I was closing the bug (we don't leave bugs in the resolved state, except for fixed bugs which are closed during release).
The bug was invalid, as it was caused by a broken native dll.
No ill intent :)
-
wine-bugs＠winehq.org