wine-bugs

wine-bugs@winehq.org

1 participants
158740 discussions

[Bug 46008] New: Support CUDA 10.0 compiled apps like new mfaktc v0.21 binary..
by wine-bugs＠winehq.org 21 May '22

21 May '22

https://bugs.winehq.org/show_bug.cgi?id=46008 Bug ID: 46008 Summary: Support CUDA 10.0 compiled apps like new mfaktc v0.21 binary.. Product: Wine-staging Version: 3.18 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: rtfss1(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 62580 --> https://bugs.winehq.org/attachment.cgi?id=62580 output Hi, just downloaded new mfaktc binary compiled with CUDA10 which adds support for new Nvidia Turing GPUs like RTX 2080.. from here: https://www.mersenneforum.org/mfaktc/mfaktc-0.21/mfaktc-0.21.win.cuda100.zip the app is a "simple" command line app so it should work OK with wine if it wasn't compiled with new CUDA10.. on Windows works ok but using latest Wine-Staging 3.18 (as staging is still required for CUDA support right?) no.. the app isn't detecting runtime version OK: CUDA runtime version 13697.32 CUDA driver version 10.0 ERROR: CUDA runtime version must match the CUDA toolkit version used during compile! full log attached.. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 7

[Bug 3548] .lnk file is created on the desktop together with the program icon...
by WineHQ Bugzilla 21 May '22

21 May '22

https://bugs.winehq.org/show_bug.cgi?id=3548 mirh <mirh(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh(a)protonmail.ch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 53024] New: wine-7.9 build fails in x86_64 Ubuntu 22.04
by WineHQ Bugzilla 21 May '22

21 May '22

https://bugs.winehq.org/show_bug.cgi?id=53024 Bug ID: 53024 Summary: wine-7.9 build fails in x86_64 Ubuntu 22.04 Product: Wine Version: 7.9 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)winehq.org Reporter: dimesio(a)earthlink.net Distribution: --- Created attachment 72396 --> https://bugs.winehq.org/attachment.cgi?id=72396 OBS log for x86_64 Ubuntu 22.04 build failure The build succeeded in i586 but failed in x86_64 Ubuntu 22.04. Builds for all other Ubuntu versions succeeded. [ 564s] /usr/bin/x86_64-w64-mingw32-dlltool: failed to open temporary tail file: winmm_dll_t.o: No such file or directory [ 564s] tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o dlls/usp10/libusp10.cross.a --export dlls/usp10/usp10.spec [ 564s] winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1 [ 564s] make[1]: *** [Makefile:139207: dlls/winmm/libwinmm.delay.a] Error 1 [ 564s] make[1]: *** Waiting for unfinished jobs.... [ 565s] make[1]: Leaving directory '/usr/src/packages/BUILD' [ 565s] dh_auto_build: error: make -j8 returned exit code 2 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 53023] New: MinecraftInstaller
by WineHQ Bugzilla 21 May '22

21 May '22

https://bugs.winehq.org/show_bug.cgi?id=53023 Bug ID: 53023 Summary: MinecraftInstaller Product: Wine Version: 7.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jon9097(a)gmail.com Distribution: --- Created attachment 72394 --> https://bugs.winehq.org/attachment.cgi?id=72394 Log The Minecraft Installer doesn't work. It won't start. I'm attaching the logs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 52188] New: Could not load file or assembly 'Windows.Foundation.UniversalApiContract
by WineHQ Bugzilla 21 May '22

21 May '22

https://bugs.winehq.org/show_bug.cgi?id=52188 Bug ID: 52188 Summary: Could not load file or assembly 'Windows.Foundation.UniversalApiContract Product: Wine Version: 6.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: julianhoyos94(a)gmail.com Distribution: --- hi everybody, i am creating scrpit for use xboxgamepass on linux, im very close but i have this error Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Windows.Foundation.UniversalApiContract, Version=7.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. file not found I would like to know if anyone has already experienced this problem, and if they have solved it since I looked on the internet, but I can't find the problem reported in wine. and I'm also looking for what it is, and I can't find anything about what program or what the error is based on, apparently it is part of Windows development libraries, I thought it was through .net but apparently it has nothing to do with it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 53011] New: Multithreaded compilation fails sometimes due to race conditions
by WineHQ Bugzilla 21 May '22

21 May '22

https://bugs.winehq.org/show_bug.cgi?id=53011 Bug ID: 53011 Summary: Multithreaded compilation fails sometimes due to race conditions Product: Wine Version: 7.7 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 72380 --> https://bugs.winehq.org/attachment.cgi?id=72380 Sample of the two broken files Sometimes the compilation fails with a message like the following: /usr/bin/i686-w64-mingw32-dlltool: dlls/mfplat/libmfplat.cross.a: error reading mfplat_dll_t.o: No such file or directory /usr/bin/i686-w64-mingw32-dlltool: dlls/rpcrt4/librpcrt4.cross.a: error reading rpcrt4_dll_h.o: file truncated /usr/bin/i686-w64-mingw32-dlltool: dlls/rpcrt4/librpcrt4.delay.a: error reading rpcrt4_dll_t.o: No such file or directory /usr/bin/i686-w64-mingw32-dlltool: bfd_open failed reopen stub file: wintrust_dll_s00009.o: No such file or directory Or sometimes files are broken: /usr/lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld: dlls/iphlpapi/libiphlpapi.delay.a: error adding symbols: file in wrong format /usr/lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/bin/ld: dlls/wintrust/libwintrust.cross.a: error adding symbols: file format not recognized If the file doesn't exist / is truncated, then trying again usually makes it work. For broken files, they need to be deleted and then you can try again. I usually compile wine like this: ALLFLAGS="-g -O0" PKG_CONFIG_PATH=/usr/lib32/pkgconfig CC="ccache gcc" CFLAGS="$ALLFLAGS" CROSSCC="ccache i686-w64-mingw32-gcc" CROSSCFLAGS="$ALLFLAGS" ../wine-git/configure --without-cups --enable-silent-rules make -j15 -sw I don't think ccache causes this, but possibly it exacerbates it.. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 52969] New: mshtml:script fails on up-to-date Windows 8.1 machines
by WineHQ Bugzilla 20 May '22

20 May '22

https://bugs.winehq.org/show_bug.cgi?id=52969 Bug ID: 52969 Summary: mshtml:script fails on up-to-date Windows 8.1 machines Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com mshtml:script fails on up-to-date Windows 8.1 machines: script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [0] got 0.00" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [1] got 1,234.50" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [2] got -1,337.73" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [3] got -0.01" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [5] got 0.00" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [6] got 99.00" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [7] got 99.00" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: [8] got 65,536.50" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: called on string threw 2148144009" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: called on undefined threw 2148144009" script.c:644: Test failed: L"/index.html?es5.js:Number toLocaleString: called on nullDisp threw 2148144009" https://test.winehq.org/data/patterns.html#mshtml:script These failures only happen on the cw-gtx560 and cw-rx460 Windows 8.1 machines. I suspect this is because these have more recent Windows updates than the TestBot's w8 and w864 machines (see bug 52858). More specifically cw-rx460 has had more recent updates than cw-gtx560 for quite some time and I further updated both on 2022-05-02. I further plan to update the TestBot's VM (the rationale being that Windows 8.1 is old and we really only care about the latest version) which should make it easier to debug. In the meantime this does seem like a regression. commit 8aefdf48f9846e05aeef3c7ce2374401982b98b4 Author: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> Date: Tue May 3 18:17:06 2022 +0300 jscript: Implement Number.prototype.toLocaleString. Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 52892] New: The 64-bit ntdll:thread fails on w7pro64 and w864
by WineHQ Bugzilla 20 May '22

20 May '22

https://bugs.winehq.org/show_bug.cgi?id=52892 Bug ID: 52892 Summary: The 64-bit ntdll:thread fails on w7pro64 and w864 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The 64-bit ntdll:thread fails on w7pro64 and w864: thread.c:153: Test failed: Multiple threads have TEB 000007FFFFFDC000. https://test.winehq.org/data/patterns.html#ntdll:thread The failure is hard to reproduce but the test was introduced by this commit: commit 6d4ec1255acceec7152ed98764ee29991ac04f10 Author: Brendan Shanks <bshanks(a)codeweavers.com> AuthorDate: Mon Apr 18 11:25:10 2022 -0700 Commit: Alexandre Julliard <julliard(a)winehq.org> CommitDate: Mon Apr 18 21:48:15 2022 +0200 ntdll/tests: Test that threads have unique TEBs. Signed-off-by: Brendan Shanks <bshanks(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> Specifically the issue is with the line below: + ok( teb1 != teb2, "Multiple threads have TEB %p.\n", teb1 ); I think the issue is that there is no guarantee that the two test threads are running at the same time. I suspect that sometimes what happens is this [1]: * status = pNtCreateThreadEx( &threads[0], ... &teb1, ... ); A new TEB is allocated, the first thread starts, sets teb1 and terminates at which time its TEB is freed. * status = pNtCreateThreadEx( &threads[1], ... &teb2, ... ); A new TEB is allocated, hey there's a fresh TEB that has just bee freed! [2]. The second thread starts and sets teb2. * WaitForMultipleObjects( 2, threads, TRUE, INFINITE ); Wait for both threads. * ok( teb1 != teb2, "Multiple threads have TEB %p.\n", teb1 ); Hey, both threads used the same TEB! But did they do so at the same time? One hacky fix would be to at a small sleep in the test threads but that's introducing race conditions. A better fix would be for the main thread to tell the test threads when they can exit through some synchronization object. [1] This may be tied to how the scheduler behaves which may limit the issue to specific Windows versions. [2] And that's probably tied to how the memory allocator behaves: more memory locality or less chance of overwriting (incorrectly) still in use memory. Again this could limit the issue to some Windows versions. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 52761] New: mscoree:mscoree test fails without a display or console
by WineHQ Bugzilla 20 May '22

20 May '22

https://bugs.winehq.org/show_bug.cgi?id=52761 Bug ID: 52761 Summary: mscoree:mscoree test fails without a display or console Product: Wine Version: 7.5 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Distribution: --- The mscoree:mscoree test fails if you run it like this: $ DISPLAY= wine mscoree_test.exe mscoree </dev/null >log 2>&1 Without the DISPLAY=, it makes a bunch of console windows. That doesn't seem to happen on Windows, but that could be caused by our csc.exe. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 46

[Bug 52937] New: msvcr110:msvcr110 fails on Windows with the UTF-8 codepage
by WineHQ Bugzilla 20 May '22

20 May '22

https://bugs.winehq.org/show_bug.cgi?id=52937 Bug ID: 52937 Summary: msvcr110:msvcr110 fails on Windows with the UTF-8 codepage Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com msvcr110:msvcr110 fails on Windows with the UTF-8 codepage: msvcr110.c:135: Test failed: expected syr-SY, got LC_COLLATE=syr-SY;LC_CTYPE=EN-US;LC_MONETARY=syr-SY;LC_NUMERIC=syr-SY;LC_TIME=syr-SY https://test.winehq.org/data/patterns.html#msvcr110:msvcr110 Note that the LC_CTYPE value in the above string corresponds to the last value it was set to. So if one tests fr-FR right before syr-SY the string contains LC_CTYPE=fr-FR. This is also why the en-US case is weird. Furthermore with a non-UTF-8 codepage setlocale() does return "syr-SY". So it looks like: 1. msvcr110 returns a long string specifying the details of the locale settings whenever they have different values. 2. msvcr110 does not support setting LC_CTYPE to syr-SY, but only when the codepage is UTF-8 for whatever reason. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs