Add option to winebuild to disable ASLR/dynamicbase
Hi, I'm a maintainer of LMMS and we use a wine bridge for loading 32-bit and 64-bit VST plugins into the Linux version of our software. We've recently updated our build tools and noticed that some of our older 64-bit VSTs fail to load. After a lot of back and forth, we've isolated the issue to the following wine commit:
Commit 518e394 julliard committed on Sep 25, 2023 winebuild: Set ASLR-related dll flags by default.
https://github.com/wine-mirror/wine/commit/518e394794160818ffe6826c874ff2f55... One of our developers has proposed a patch which reverts this behavior here: https://github.com/Fastigium/winebuild/commit/7f9e27e44cfb8eba79f3850f46e12f... My questions are as follows: 1. Would winehq be receptive to a winebuild flag that allows the old behavior? 2. If acceptable, would you prefer LMMS author this patch, or is this change trivial enough/small enough that the winehq team would prefer to tackle it themselves? 3. Lastly, quoting a past mailing list convo, should we be doing our wine bridge differently? Currently we build RemovePluginVst64.so.exe. "[...] I don't think we have any plans to deliberately break the old all-in-one .dll.so binaries. It is quite likely that this functionality will bitrot over time though. Also the functionality that the PE/unix split was introduced for won't be available that way [...]" Source: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/mes... Thanks kindly for your time, -Tres - Tres.Finocchiaro(a)gmail.com
On Tue, Jul 8, 2025, 00:41 Tres Finocchiaro <tres.finocchiaro(a)gmail.com> wrote:
1. Would winehq be receptive to a winebuild flag that allows the old behavior?
Probably not. Wine's goal is first and foremost emulation of Windows
userspace, and Windows uses DYNAMICBASE and HIGH_ENTROPY_VA for its DLLs.
1. If acceptable, would you prefer LMMS author this patch, or is this change trivial enough/small enough that the winehq team would prefer to tackle it themselves?
1. Lastly, quoting a past mailing list convo, should we be doing our wine bridge differently? Currently we build RemovePluginVst64.so.exe.
"[...] I don't think we have any plans to deliberately break the old all-in-one .dll.so binaries. It is quite likely that this functionality will bitrot over time though. Also the functionality that the PE/unix split was introduced for won't be available that way [...]"
Source: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/mes...
Yes, ideally you're supposed to not rely on specific address of DLLs. If
you want to call Unix-specific APIs, the most up-to-date way to do is to use something called *unixlibs*. I'm not aware of any documentation or tutorial, but you can consult existing DLLs like wpcap, mountmgr.sys, or winscard (or anything that uses WINE_UNIX_CALL). -- Jinoh
Wine's goal is first and foremost emulation of Windows userspace, and Windows uses DYNAMICBASE and HIGH_ENTROPY_VA for its DLLs.
Hi, I'm not sure I understand this stance since both mingw and msvc provide full control over the DYNAMICBASE flag at compile time. In our case, we MUST be able to control this flag for compatibility with older DLLs to maximize compatibility with our software, otherwise the non-Windows versions of LMMS would have an artificially imposed regression/limitation over versions targeting Windows directly. In practice, this means that a large percentage of older VST plugins will just stop working overnight, simply because we used a modern version of wineg++ to compile our bridge. I'm not aware of any documentation or tutorial, but you can consult
existing DLLs like wpcap, mountmgr.sys, or winscard (or anything that uses WINE_UNIX_CALL).
Thanks for the pointer. Depending on how successful (or more specifically, lack thereof), we may need to build a custom winebuild for the foreseeable future. We already plan to do this for the short-term, but as other wineg++ apps run into crashes when ASLR/DYNAMICBASE is enabled, this is likely to be requested again in the future.
We've recently updated our build tools and noticed that some of our older 64-bit VSTs fail to load.
Sorry if this initial statement was ambiguous, but for clarification, LMMS doesn't actually build any VST DLLs. Instead, these are 3rd-party VST DLLs (usually music instruments and audio effects) that have been created over the past 25 years (largely for commercial software like FLStudio, Ableton, Acid, etc) that LMMS also tries to be compatible with. Since they're loaded with our LMMS-wine-bridge (RemoteVstPlugin.so.exe), we're directly impacted by the addition of DYNAMICBASE of this executable. Our unit-testing is using the Synth1 DLL which was created in 2014 https://daichilab.sakura.ne.jp/softsynth/index.html.
On Monday, 7 July 2025 17:45:55 CDT Jinoh Kang wrote:
On Tue, Jul 8, 2025, 00:41 Tres Finocchiaro <tres.finocchiaro(a)gmail.com> wrote:
1. Would winehq be receptive to a winebuild flag that allows the old behavior?
Probably not. Wine's goal is first and foremost emulation of Windows userspace, and Windows uses DYNAMICBASE and HIGH_ENTROPY_VA for its DLLs.
It's also rather worth investigating why this happens...
1. Lastly, quoting a past mailing list convo, should we be doing our wine bridge differently? Currently we build RemovePluginVst64.so.exe.
"[...] I don't think we have any plans to deliberately break the old all-in-one .dll.so binaries. It is quite likely that this functionality will bitrot over time though. Also the functionality that the PE/unix split was introduced for won't be available that way [...]"
Source: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel(a)winehq.org/mes...
Yes, ideally you're supposed to not rely on specific address of DLLs. If you want to call Unix-specific APIs, the most up-to-date way to do is to use something called *unixlibs*.
I'm not aware of any documentation or tutorial, but you can consult existing DLLs like wpcap, mountmgr.sys, or winscard (or anything that uses WINE_UNIX_CALL).
Building split PE DLLs outside of the Wine build system is a lot less trivial, and while there's been basically no communication from the Wine project about deprecation or API stability, I'm inclined to believe there's no stable way to do it. (Frankly, as far as I can tell, the Wine project intends to simply deprecate and remove the ability to build external DLLs due to perceived lack of use.) If you're able to deal with the instability, I've written up some instructions here: https://bugs.winehq.org/show_bug.cgi?id=58377#c6
Elizabeth Figura <zfigura(a)codeweavers.com> writes:
Building split PE DLLs outside of the Wine build system is a lot less trivial, and while there's been basically no communication from the Wine project about deprecation or API stability, I'm inclined to believe there's no stable way to do it. (Frankly, as far as I can tell, the Wine project intends to simply deprecate and remove the ability to build external DLLs due to perceived lack of use.)
There are no plans to remove that ability. It's true that there's currently no stable, supported way to build external PE dlls with a Unix side, but that's mostly because there's nobody who cares enough about it to invest time into designing and implementing that support. Help is welcome. -- Alexandre Julliard julliard(a)winehq.org
There are no plans to remove that ability. It's true that there's currently no stable, supported way to build external PE dlls with a Unix side, but that's mostly because there's
So would it be inappropriate for me to ask again, why adding a flag to winebuild to influence the PE section of a Unix SO -- specifically for compatibility with older, 3rd-party DLLs that we don't have the ability or interest modifying -- would be frowned upon? (particularly as opposed to the seemingly more complex WINE_UNIX_CALL approach)
"nobody who cares enough about it to invest time into designing and implementing that support."
I feel this. LMMS is a project that's forever been barely held together by a shoestring team of bug hunters. The wine bridge that it uses -- specifically --- has long been a mystery to the team and troubleshooting issues with it often turn to burn-out. We're fortunate to have had a musician step in to deep-dive on this crash, but this is without consequence... quoting:
"(potentially off-topic but relevant to the pace of this work: day before yesterday I kinda collapsed after opening PR #7987 . I took a break yesterday and am feeling somewhat better today, but my body is telling me in no uncertain terms that I need to put less pressure on myself working on all this. I'm gonna try to take it slower, but I'm not sure how much I'll be able to get done in the near future, especially if things escalate into a lot of extra complexity)"
Searching for 'winebuild', 'winegcc' or 'wineg++' in SCMs like GitHub show a very short list of results (many of which are simply wine mirrors). Doing the same on stackoverflow yields 65 results for all three keyworks combined, which makes it hard to gauge the importance or longevity of a tool. At the end of the day, what LMMS hopes for is a way to run a DLL file at maximum compatibility from a native *nix app. I don't know much about the inner workings, but it's a feature we'll keep in the software for as long as we can maintain it. I've even added experimental support to our ARM64 Linux versions (not yet working) and I would like to eventually add support to our macOS versions as well (missing winegcc). I digress. Help is welcome. I can offer a patch to add this feature to winebuild, but since this offer was initially shot down, I'm not sure the best way to proceed. I understand by maintaining other FOSS projects, adding a flag isn't the same as "helping" a project and I don't want to escape obligation here, but we too are struggling with help on the LMMS side and I hope that my request is seen as a humble ask and not as demanding or needy. We'd like to support these older DLLs for the short-term using a technique we know works and long-term a technique we would expect to eventually work and were receptive to change but also extremely limited on "help". <3
Tres Finocchiaro <tres.finocchiaro(a)gmail.com> writes:
There are no plans to remove that ability. It's true that there's currently no stable, supported way to build external PE dlls with a Unix side, but that's mostly because there's
So would it be inappropriate for me to ask again, why adding a flag to winebuild to influence the PE section of a Unix SO -- specifically for compatibility with older, 3rd-party DLLs that we don't have the ability or interest modifying -- would be frowned upon? (particularly as opposed to the seemingly more complex WINE_UNIX_CALL approach)
Disabling the flag may or may not be the right solution, but the first thing is to understand exactly why that flag is breaking your app. Filing a bug would be a good first step.
Searching for 'winebuild', 'winegcc' or 'wineg++' in SCMs like GitHub show a very short list of results (many of which are simply wine mirrors). Doing the same on stackoverflow yields 65 results for all three keyworks combined, which makes it hard to gauge the importance or longevity of a tool.
At the end of the day, what LMMS hopes for is a way to run a DLL file at maximum compatibility from a native *nix app. I don't know much about the inner workings, but it's a feature we'll keep in the software for as long as we can maintain it. I've even added experimental support to our ARM64 Linux versions (not yet working) and I would like to eventually add support to our macOS versions as well (missing winegcc). I digress.
Not that both ARM64 and macOS will require a PE build. There's no way to make a .so dll work on these platforms because their Unix ABI is not compatible with the Windows one. -- Alexandre Julliard julliard(a)winehq.org
Disabling the flag may or may not be the right solution, but the first thing is to understand exactly why that flag is breaking your app. Filing a bug would be a good first step.
Disabling the flag is how we need to fix this for older DLLs on MSVC and mingw. Can you help me understand what the purpose of a bug report to winehq is? I certainly don't mind writing one, but this issue is "solved" for other DLL compilers. Quoting the PR-thats-leading-to-burnout from our gracious user:
"Address Space Layout Randomization (ASLR) is a security technique that randomizes the location of several key memory areas in order to make it harder to use memory corruption exploits (Wikipedia). Sadly, several old VST dlls crash when ASLR is in use (see bug #7830). This PR adds linker flags to disable ASLR when building RemoteVstPlugin Windows executables. The main program (lmms.exe) is still built with ASLR enabled"
Note that this regression aligns with both mingw AND wine addition of DYNAMICBASE features. Finding this regression actually FINALLY allows these VST plugins to work with MSVC which they never have before, so we're actually very excited about this flag. What's hard for me to speak on behalf of -- please accept my apologies here -- is that I'm not a very "good" C/C++ developer despite my tenure on the LMMS project -- so, if this crash could be avoided through other means I'm not sure, however I'm also not sure how far down the rabbit hole we would need to (or should?) go for this to be properly explained (nor whether or not I'm qualified to understand or explain this). LMMS has an external plugin system, we load a plugin for handling the IPC stuff and that plugin -- which we call RemoteVstPlugin[32|64].exe -- is responsible for starting and interacting with the DLL. In the case of the Synth1 instrument mentioned in an earlier email, the plugin plays a single note fine, but crashes when a second note is played. Using a debugger on this is difficult due to the the lmms --> remote plugin --> vst plugin, however as a project maintainer, I trust and follow the findings of this musician/developer helping. The TL;DR of this is in our Discord #dev-forum thread here: https://discord.com/channels/203559236729438208/1383830615429877851 (invite link available via https://lmms.io/chat) where the OP and I have spent weeks trying various things to isolate this regression. Mingw even mentions the possibility of this breaking things in their changelog, quoting: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default
2021-01-31 - ASLR enabled by default
About 5 months ago we started backporting patches to our binutils 2.35 to allow enabling ASLR support via various flags. We also enabled these flags in our build system, so any package in our repo that was updated in the last 5 months has ASLR support enabled.
We've now updated to 2.36 which has ASLR enabled by default. Ideally you shouldn't notice any changes, but in case this leads to problems all of it can be disabled/reverted via linker flags:
mingw64: -Wl,--disable-dynamicbase,--disable-high-entropy-va,--default-image-base-low mingw32: -Wl,--disable-dynamicbase
Note that this is only a temporary workaround and some of these flags will not be available forever, so you should either fix your code or file a bug in case you suspect a toolchain issue.
As an argument AGAINST this flag for winebuild, mingw DOES warn against this flag as being a candidate for future removal, however since MSVC makes no mention of removing this build option on the Windows-side, I'm hopeful that mingw mimics Microsoft's lead on this platform. https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase I'd be happy to write-up a bug report if you think it's helpful, but I'm not certain I'll have PE (or even LMMS code) knowledge needed to "explain why this flag is breaking our app" aside from the high-level fact that these DLLS we talk to are often older than Vista when this feature was added.
participants (4)
-
Alexandre Julliard -
Elizabeth Figura -
Jinoh Kang -
Tres Finocchiaro