http://bugs.winehq.org/show_bug.cgi?id=58480
Bug ID: 58480 Summary: winebuild ASLR breaks older DLLs Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: tres.finocchiaro@gmail.com Distribution: ---
The following commit (to the best of my understanding) introduces build flags to the PE sections of a wineg++ produced '.so.exe' file that force ASLR/DYNAMICBASE onto executables that it creates.
https://github.com/wine-mirror/wine/commit/518e394794160818ffe6826c874ff2f55...
As identified downstream with mingw and msvc, some scenarios exist where this ASLR/DYNAMICBASE must be disabled for the highest compatibility with 3rd-party DLLs, specifically 3rd-party VST instrument and effect plugins as they're loaded through DAWs using a Linux-wine-bridge. (Linux can be read ambiguously here, the issue would impact Unixes too)
The downstream bug report encompases Windows and Wine instances of the LMMS application, however a solution exists on Windows for both the MSVC compiler as well as the mingw compiler (via relevant dynamicbase flags).
MSVC: https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase
mingw: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default
Applying a similar flag to wineg++/winegcc/winebuild has proven difficult without forking the winebuild executable. The stop-gap patch that LMMS has developed is provided here as a reference https://github.com/Fastigium/winebuild/commit/7f9e27e44cfb8eba79f3850f46e12f... however this patch requires us to add winebuild as a build-time dependency to our build system. This is OK for a stop-gap, but as a long-term solution, I would like advice from the winehq team on how to support legacy DLLs (such as pre-Vist VST plugins) through a wine-bridge as a long-term solution.