@rbernon Confirming wine-staging is not a dependency for yabridge new-wine10-embedding branch which works for 75b9e1722d1 Release 10.13.
Varities of music apps that depend on yabridge are being tested. So far Carla has worked best for me with the least minor issues. Others reported more minor issues for other apps like Bitwig.
Yabridge new-wine10-embedding branch seems to behave differently depending on which app is used like Carla vs Bitwig.
I'm now mostly operating under assumptions that the changes in this merge request are valid per more review of the code and all comments including the contributions to yabridge.
Because Yabridge was modded for compatibility with the latest Wine changes I lean toward the same needing to happen for these other apps.
I will take a look at how Carla handles yabridge windowing wrapping to compare against apps that are not behaving as well.
Maybe those other apps need to be modded for compatibility with yabridge new-wine10-embedding branch or some backwards compatible fix may be found.
Changes of this merge request also broke LMMS Vestige plugin which is a VST handler independent of yabridge so that project seems to have made similar assumptions about how Wine would handle their VST windowing behaviors. I will also be comparing yabridge against LMMS Vestige for a solution compatible with this merge.
I'll continue to post any relevant findings back to this issue.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113376
On Wed Aug 20 20:08:15 2025 +0000, Tres Finocchiaro wrote:
> From my understanding, `winebuild` influences the PE section of this
> binary, which IS meaningful. This is reinforced by the fact older
> `.dll` plugins stop crashing when it's disabled, and that other PE
> compilers offer similar options to control these flags.
> The `HIGHENTROPYVA` should have no effect if `DYNAMICBASE` is off, so I
> can see a "not meaningful" there (but only on mutual exclusion), but I
> wanted to keep the PR as simple as possible.
> I understand that Unix has [its own ASLR that's on by
> default](https://askubuntu.com/questions/318315), but to deny the
> meaningfulness of this flag for the PE section of the binary seems --
> respectively -- incorrect. This regression was introduced with
> 518e394794160818ffe6826c874ff2f550c95bbb and can be reverted just the
> same. I'm only asking to give `winegcc` (or more specifically
> `winebuild`) 'users' the ability to control it.
The only influence is when both flags are set, we stop allocating in the low 2Gb by default, which probably breaks plugins that have pointer truncation bugs.
Unless both flags are set together, there shouldn't be any difference for the case of `.exe.so` binaries. There are more differences for the case of PE binaries, but that's controlled by the flags passed to `mingw`, not to `winebuild`.
So there's no reason to add two separate options to `winebuild`. Clearing either flag is the same as clearing both.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113356