Tres Finocchiaro tres.finocchiaro@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.