How to build in MSYS2+MinGW on Windows host? about vis_avs HOT 3 OPEN

Hi there!

I have never used MSYS myself, really. So I don't really know much about it. It's a GNU-ish toolset for Windows, right?

For vis_avs, only GCC-on-Linux and MSVC-on-Windows are currently available. I'd have to test an MSYS installation on Windows. Is MSYS the most common way to go to get GCC on Windows? Or is there a "pure" MinGW-w64-GCC/-Clang toolchain one could also use instead?

What is a "fully static DLL"? One with no further DLLs linked in? Or a .lib/.a static library archive? Because a DLL itself is dynamically linked by definition, no?

I'm not opposed to this, quite the opposite, but there's two prerequisites:

• The vis_avs Winamp plugin has to become the libavs library (i.e. #11 should be done). This will take some months!
• The build should actually run on Windows (right now it only compiles and loads into Winamp, and even that only under specific circumstances, and it has all sorts of issues at runtime 😞). It only works properly under Wine on Linux.

from vis_avs.

I am no developer, only a halfwit using automated build scripts, sometimes reporting issues with slightly founded experience. So I hope to provide at least a few breadcrumbs out of the thicket...

I have never used MSYS myself, really. So I don't really know much about it. It's a GNU-ish toolset for Windows, right?

MinGW is a "Minimal GNU for Windows", and MSYS2 provides a wholesome distribution as environment for software development with Unix like tools under Windows. It provides an own installer and package management (via pacman).

What is a "fully static DLL"? One with no further DLLs linked in?

That's what I mean: No dependencies to runtime DLLs specific to a cross compilation subsystem (what you often have with cygwin). I would exclude from this demand e.g. MS VC Runtime DLLs from Visual Studio builds as they are common and shared between a large number of applications, and are available on many Windows PCs already. I remember that MinGW GCC builds may use some older, basic versions of their shared functions as well (msvcrt.dll), so this is a common exception.

The media-autobuild suite, when compiling codecs for ffmpeg or as separate executables, takes care with specific configuration options, sometimes additional patches, to produce e.g. an ffmpeg.exe with no external dependencies (except you configure your desired selection of codecs with one that does not support static linking and is only available as dependent DLL, like openh264, or loads a DLL on demand when a specific function is used, like VapourSynth script support).

You can configure the media-autobuild suite to actually not do much, except keeping an MSYS2+MinGW environment up to date. This may be a quite convenient alternative to the default MSYS2 installer.

from vis_avs.

Thanks for the in-depth explanations.

I'll keep MSYS2 in mind, once libavs is ready. Right now it's of little use on Windows.

from vis_avs.