On Sat Dec 3 04:33:26 2022 +0000, Brendan Shanks wrote:
> Hmm, and this worked correctly before? Are you running from the build directory?
> I didn't realize this before, but any DYLD_ environment variables will
> be stripped when running from the build directory, because `./wine` or
> `./wine64` is a shell script, and system binaries (including `/bin/sh`)
> ignore/strip `DYLD_` env vars. But if you edit `wine`/`wine64` and
> set/export `DYLD_FALLBACK_LIBRARY_PATH` inside the script, it works.
> Or, if you install Wine and then run it from there, `wine`/`wine64` is a
> binary, so `DYLD_FALLBACK_LIBRARY_PATH` works correctly.
> I did some tests with the preloader and couldn't find any cases where it
> loses or mishandles the environment variables.
Yes, this is from the build dir. I'm setting `DYLD_FALLBACK_LIBRARY_PATH` in `.winewrapper` to avoid the issue of `/bin/sh` stripping the `DYLD_` variables, which worked before the mentioned commit.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1616#note_18558
On Sat Dec 3 04:33:26 2022 +0000, Huw Davies wrote:
> commit 588e5554252 is preventing a 32-bit build on Mojave from finding
> the 32-bit libfreetype.6.dylib which I have in a non-standard location.
> I suspect that DYLD_FALLBACK_LIBRARY_PATH is somehow being lost.
Hmm, and this worked correctly before? Are you running from the build directory?
I didn't realize this before, but any DYLD_ environment variables will be stripped when running from the build directory, because `./wine` or `./wine64` is a shell script, and system binaries (including `/bin/sh`) ignore/strip `DYLD_` env vars. But if you edit `wine`/`wine64` and set/export `DYLD_FALLBACK_LIBRARY_PATH` inside the script, it works.
Or, if you install Wine and then run it from there, `wine`/`wine64` is a binary, so `DYLD_FALLBACK_LIBRARY_PATH` works correctly.
I did some tests with the preloader and couldn't find any cases where it loses or mishandles the environment variables.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1616#note_18544
The test for ISmbiosInformationStatics_get_SerialNumber is broken on Window 10 testbot VMs, presumably because they don't have a serial number? It results in an HRESULT of E_UNEXPECTED. I added a broken test case for it. I'm assuming that normal installations of Windows return a valid serial number or at least something like "Not Specified" and not NULL. Also, on my Linux OS running cat /sys/class/dmi/id/product_serial returns "To be filled by O.E.M". So I added a fallback to return 0 as the number. Or is it fine to just return whatever string is found?
On the Windows 8 VMs, the test crashes at line 75, hr = ISmbiosInformationStatics_get_SerialNumber( smbios_statics, &serial ). Not sure what I should do in this case. I was hoping for a flag that checks if the VM is Windows 8, but there doesn't seem to be one. Should I wrap the test in if (0) or is there an alternative way?
Another weird thing is the test fails prematurely on only the 32-bit version of debian11b, saying that the runtimeclass is not registered. I'm assuming it's an issue with the testbot. Debian11 32 bit runs fine.
--
v5: windows.system.profile.systemmanufacturers: Implement ISmbiosInformationStatics_get_SerialNumber.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1588
> * direct call: 5761
> * unpatched Wine: 13933
> * ret.diff: 6823 (55% time spent in \__wine_unix_call_dispatcher, 29% in PE vkGetPhysicalDeviceProperties)
>
> Looks impressive!
Thanks, committed as 0aae4b05633cb9b38eb37cc662f5a3aadb3ce108. Can we get rid of direct calls now? :wink:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1552#note_18536