Re: Add option to winebuild to disable ASLR/dynamicbase

Tres Finocchiaro <[email protected]> Wed, 9 Jul 2025 14:52:25 -0400
Newsgroups gmane.comp.emulators.wine.devel
Message-ID <CANQs7dDKeBYBbUrj0sx_kDAFjbKgVCxf-cD3wX=p5UROJ1i8eg@mail.gmail.com>
>
> 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