Re: Add option to winebuild to disable ASLR/dynamicbase

Tres Finocchiaro <[email protected]> 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
[email protected]