https://bugs.winehq.org/show_bug.cgi?id=54635
Bug ID: 54635
Summary: libwine backward compatibility
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winecrt0
Assignee: wine-bugs(a)winehq.org
Reporter: a.heider(a)gmail.com
Distribution: ---
v8.3 finally removed libwine.
Older winegcc builds automatically link against it (just
__wine_dll_register(a)WINE_1.0 in out case).
Newer winegcc builds don't link against it anymore, it looks like since
f6a363bc4108f3d45b7a5bac706d10579f4d2772 "winecrt0: Get rid of constructor
support." v5.7.
We build downloadable releases and would like to keep maximum binary
compatibility.
Building with >=v5.7 would likely avoid the issue, but I guess binaries won't
work on older WINE versions then.
For the record: Ubuntu 18.04 LTS is about to go unsupported, 20.04 LTS ships
v5.0. Our current CI setup uses 20.04, so v5.0, to build releases.
Is there something we can do to make built binaries work on >=v5.0?
Any suggestions how to archive that? Something on our end? Or maybe WINE can
get a compatibility addition to skip the
libwine.so.1/__wine_dll_register(a)WINE_1.0 symbol or something?
Thanks!
Andre
--
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.
http://bugs.winehq.org/show_bug.cgi?id=37056
Bug ID: 37056
Summary: Rapture3D requires native dsound.dll in order to
change sound layout.
Product: Wine
Version: 1.7.23
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-dsound
Assignee: wine-bugs(a)winehq.org
Reporter: El_Diablo2(a)gmx.de
Created attachment 49248
--> http://bugs.winehq.org/attachment.cgi?id=49248
Error message with builtin dsound.dll
With builtin dsound UserLayout.exe complains it cannot change the soundcard
configuration.
No interessting (default channels) debug output...
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54686
Bug ID: 54686
Summary: LibvirtTool sometimes fails to update the time
Product: Wine-Testbot
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
When reverting to a live snapshot it is necessary to update the VM's time so
certificate checks and more work as expected. This is handled by LibvirtTool.pl
via using the SetTime TestAgent RPC.
However there are some cases where this fails as is evidenced by job 130592:
w10pro64v2004 LocalTime: 2023-03-14 2 10:47:10.744
w10pro64 LocalTime: 2022-12-11 0 14:18:16.343
w10pro64_fr LocalTime: 2023-03-14 2 10:46:42.143
So the time did not get updated on w10pro64 while it did get updated on all of
that job's 4 other VMs. Furthermore there is evidence that during that day's
nightly WineTest runs it is w10pro64v2004 that did not get a time update (or
the time reverted back?).
Failure to update the time can cause test failures so it needs to be reliable.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54685
Bug ID: 54685
Summary: The localized VMs don't have a localized timezone
Product: Wine-Testbot
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The base VM configurations are all in the Minnesota timezone (CST / CDT).
But the localized ones should be in the timezone corresponding to the country.
For instance the French test configuration should be in the CET / CEST
timezone.
But SetWinLocale does not support changing the timezone.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54659
Bug ID: 54659
Summary: d3d8:device & d3d9:device sometimes get floating point
underflow in GenerateRampFromGamma() in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: d3d
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
d3d8:device & d3d9:device sometimes get an floating point underflow exception
in GenerateRampFromGamma() in Wine:
d3d8:device start dlls/d3d8/tests/device.c
Unhandled exception: floating point underflow in 32-bit code (0x7e91438f).
[...]
Backtrace:
=>0 0x7e91438f in libm.so.6 (+0x2538f) (0x0069ef68)
1 0x7e922d3b in libm.so.6 (+0x33d3b) (0x0069ef68)
2 0x7e55c181 GenerateRampFromGamma+0x51(ramp=00197C4C, gamma=0.000300)
[Z:\home\winetest\tools\testbot\var\wine\dlls\winex11.drv\xvidmode.c:336] in
winex11.so (0x0069ef68)
3 0x7e55c9b2 X11DRV_XF86VM_GetGammaRamp+0x60(ramp=<internal error>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\winex11.drv\xvidmode.c:519] in
winex11.so (0x0069ef68)
4 0x7e55c9b2 X11DRV_GetDeviceGammaRamp+0x82(dev=<couldn't compute location>,
ramp=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\winex11.drv\xvidmode.c:569] in
winex11.so (0x0069ef68)
5 0x7ea32408 NtGdiGetDeviceGammaRamp+0x88(hdc=<couldn't compute location>,
ptr=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\win32u\dc.c:1247] in win32u.so
(0x0069efb8)
6 0x64a8d74c NtGdiGetDeviceGammaRamp+0x2c(hdc=<couldn't compute location>,
ptr=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\win32u\wrappers.c:280] in win32u
(0x0069efe8)
7 0x6ccf9d3d wined3d_output_get_gamma_ramp+0x4d(output=00140E10,
ramp=00197C4C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\directx.c:1741] in
wined3d (0x0069f028)
8 0x6cd5fcb0 wined3d_swapchain_get_gamma_ramp+0x30(swapchain=00197C30,
ramp=00197C4C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\swapchain.c:385] in
wined3d (0x0069f058)
9 0x6cd61190 wined3d_swapchain_init+0x3c0(swapchain=<register EBX not
accessible in this frame>, device=<register EDI not accessible in this frame>,
desc=<internal error>, state_parent=00140D5C, parent=00140D50,
parent_ops=67CDE7D4, swapchain_ops=6CE6933C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\swapchain.c:1633] in
wined3d (0x0069f168)
10 0x6cc8d9f3 adapter_gl_create_swapchain+0x73(device=0017B3E8,
desc=0069F2BC, state_parent=00140D5C, parent=00140D50, parent_ops=67CDE7D4,
swapchain=0069F1FC)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\adapter_gl.c:4701] in
wined3d (0x0069f1b8)
11 0x6cd5fdd1 wined3d_swapchain_create+0x41(device=0017B3E8, desc=0069F2BC,
state_parent=00140D5C, parent=00140D50, parent_ops=67CDE7D4,
swapchain=00140D58)
[Z:\home\winetest\tools\testbot\var\wine\dlls\wined3d\swapchain.c:1724] in
wined3d (0x0069f208)
12 0x67ccfe84 swapchain_init+0x48(swap_interval=<internal error>,
desc=<internal error>, device=<internal error>, swapchain=<internal error>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\swapchain.c:180] in d3d8
(0x0069f248)
13 0x67ccfe84 d3d8_swapchain_create+0x84(device=001468F0, desc=0069F2BC,
swap_interval=0xffffffff, swapchain=0069F290)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\swapchain.c:199] in d3d8
(0x0069f248)
14 0x67ccc467 device_init+0x217(device=001468F0, parent=00140A90,
wined3d=00140AB0, adapter=0, device_type=D3DDEVTYPE_HAL, focus_window=0003004A,
flags=0x42, parameters=0069F53C)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\device.c:3744] in d3d8
(0x0069f478)
15 0x67ccd649 d3d8_CreateDevice+0xa9(iface=<couldn't compute location>,
adapter=<couldn't compute location>, device_type=<couldn't compute location>,
focus_window=<couldn't compute location>, flags=<couldn't compute location>,
parameters=<couldn't compute location>, device=<couldn't compute location>)
[Z:\home\winetest\tools\testbot\var\wine\dlls\d3d8\directx.c:438] in d3d8
(0x0069f4e8)
16 0x004010ce in d3d8_test (+0x10ce) (0x0069f588)
...
This does not happen in the nightly Wine test runs but impacted at least two
merge requests:
* MR2072, repeatedly
* MR2217, repeatedly
There are three immediate questions:
* Where does the 0.000300 gamma come from?
I don't think such a value makes sense so I suspect it's caused by a bug
somewhere.
* Should xvidmode.c's GenerateRampFromGamma() crash in case of underflow (or
overflow for that matter)?
If not, ComputeGammaFromRamp() should probably be fixed too. Which other
functions have the same issue? (not just in xvidmode.c)
* By default underflows don't cause exceptions. So which piece of code in
d3d8:device does a _control87(0, _EM_UNDERFLOW) ?
Then, why does this failure not happen more often?
The debian11 VM ran the tests multiple times in a row to test various locales:
en -> success
ar:MA -> success
de -> success
fr -> underflow
he:IL -> underflow
hi:IN -> underflow
ja:JP -> underflow
zh:CN -> underflow
While the wineprefix is recreated for each test, all the tests run on the same
X server session. So my theory is that one of the tests in the first three runs
progressively degraded the gamma at the X level, such that all the tests that
followed got a bad gamma from the X server and crashed. Furthermore note that
the first plain 32-bit run ran the full Wine test suite. That may have been a
factor too.
MR2217 caused the following tests to run so the guilty party should be among
them:
d3d8:device d3d9:device ddraw:ddraw1 ddraw:ddraw2 ddraw:ddraw4 ddraw:ddraw7
That explains why this failure does not happen in the nightly Wine test runs:
each is done after restoring the VM to a clean state. Similarly, other merge
requests may run fewer tests so that the gamma does not get degraded that much.
That leaves a mystery though: I don't get this issue on my desktop (fg-deb64)
despite running the tests every night and not ever restarting the X server
(thankfully!). Maybe this gamma issue is caused by a bug that only happens with
the VM environment (likely QXL GPU or dual screen configuration, such that it
does not happen on single-screen Intel GPUs)?
--
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.
https://bugs.winehq.org/show_bug.cgi?id=53553
Bug ID: 53553
Summary: F.E.A.R. won't work with DSOAL surround sound
restoration DLL replacement
Product: Wine
Version: 7.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: dsound
Assignee: wine-bugs(a)winehq.org
Reporter: mr.matt.eastwood(a)gmx.de
Distribution: ---
Steps to Reproduce:
1. Install F.E.A.R. (e.g., "Fear Platinum" from GOG)
2. Get DSOAL from https://github.com/kcat/dsoal and compile dsound.dll
3. Get latest OpenAL-Soft bin from https://openal-soft.org/
4. Unzip soft_oal.dll from its bin\Win32 directory
5. Rename that file to dsoal-aldrv.dll
6. Place both dsoal-aldrv.dll and DSOAL's dsound.dll in same directory as
FEAR.exe
7. Run game
8. Enter sound menu
Expected Results:
When running F.E.A.R. with the DLL replacement DSOAL for surround sound
restoration, the advanced sound options "Enable HW mixing", "Enable EAX 2.0"
and "Enable EAX Advanced HD" should be available in the sound menu and surround
sound including EAX effects should work.
Current Results:
The sound options remain greyed-out.
Observations:
F.E.A.R. won't load dsound.dll from anywhere but syswow64. If one places the
DSOAL dsound.dll there (replacing Wine's own), and then sets dsound.dll to
"native" e.g. through winecfg, everything works. Screenshot:
If one sets dsound.dll to "native" e.g. through winecfg and then loads the game
without replacing Wine's dsound.dll in syswow64 (but with the DSOAL files in
the F.E.A.R. folder): "Failed to initialize sound driver 'SndDrv.dll' on
startup. Screenshot: https://paste.pics/I4DO0. No sound during game or menus,
only during intro movie. Available sound options: https://paste.pics/I4DOD
--
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.
https://bugs.winehq.org/show_bug.cgi?id=49915
Bug ID: 49915
Summary: can not register COM server
Product: Wine
Version: 5.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ysong2180(a)yahoo.com
Distribution: ---
Created attachment 68286
--> https://bugs.winehq.org/attachment.cgi?id=68286
two log files. one is the winecfg log. The other one is the application log
I tried to install an windows application on Ubuntu 20.04. The installer can
run and install files. But it fails at the end when it tries to register COM
servers. It is a win32 application. I used winecfg to create a win32
wineprefix and used the win32 wineprefix to start the installer.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54677
Bug ID: 54677
Summary: Wine cannot find tools in tool dir when cross
compiling
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tools
Assignee: wine-bugs(a)winehq.org
Reporter: ale.schenberg(a)yandex.com
Distribution: ---
Created attachment 74193
--> https://bugs.winehq.org/attachment.cgi?id=74193
config.log
Hello. When trying to cross build wine, configure's execution breaks due to it
to not find wine tools in the tools dir.
My building command:
LDFLAGS=-Wl,--dynamic-link=/usr/lib32/ld-2.17.so ./configure
--host=i686-gnu-linux --with-wine-tools=tools/
I attached config.log, although it appears to contain no useful information.
The bug applies to wine 8.3 and any other wine version that I tested (such as
1.9)
I think its worthy to mention that cross build it is more a necessity imposed
by the configure script than my wish. As I am forced to pass
"LDFLAGS=-Wl,--dynamic-link=/usr/lib32/ld-2.17.so" to configure (if not, the
building won't be able to run any auxiliary 32bit components, such as makedep,
unless I statically build them), configure demands the use of host, and then of
--with-wine-tools
--
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.