Birch-san
commented
11 months ago I know the maintainer uses OSX to develop, so I urge anybody reading this who uses a Windows machine to try to replicate it.
Windows isn't a confounding factor; you're (cross-)compiling this in a Linux virtual machine + container, just like I do. the Dockerfile worked at the time I made it, but some of the dependencies it's fetching have undergone changes since the time it was last working. we've been forced onto a new major version of pcre, for example (probably indicates that glib updated -- glib uses pcre to implement regex).
A potential solution may be to try using the posix version of mingw
hmm I don't think there's anything here that suggests that the compiler toolchain is making a mistake. I think this would happen even if you changed toolchain. if you stick with the current toolchain, then you at least don't have to solve cross-compilation, because that's known-good.
and msys2 mingw64 installed on Windows 10
the compilation happens inside a container, inside a WSL Linux virtual machine. so it doesn't matter what's installed on Windows — the compilation's happening inside a Linux container.
the build fails while building fluidsynth
actually it built fluidsynth successfully, then proceeded on to the next step: building juicysfplugin.
but we're doing static linking (the goal is to create a single-file .exe or .dll with all libraries included inside it, instead of a folder of .dlls), so the libfluidsynth we're linking in, doesn't actually come with its own dependencies (e.g. glib).
so, when building a statically-linked juicysfplugin: our job is to know what dependencies we have, and what dependencies they have, and make sure we include them all in our build.
whereas usually people do dynamic-linking, where you're only responsible for linking in your immediate dependencies, not your transitive dependencies too.
ordinarily, pkgconfig is supposed to be the mechanism for juicysfplugin's build to lookup what fluidsynth's dependencies were, and from there it would learn that to build juicysfplugin: we'll need to link in glib, to ensure fluidsynth can work.
so, I think something's missing in fluidsynth's pkgconfig output. ordinarily it's supposed to include some linker flags saying to go find glib. maybe that mechanism failed, or maybe it's resulted in the wrong glib being included, or glib being included but not its dependencies.
DaforLynx
When running
docker build . -f win32.Dockerfile --tag=llvm-mingwas per instructions with WSL and msys2 mingw64 installed on Windows 10, the build fails while building fluidsynth with "undefined symbol: __declspec(dllimport)" errors related to glib2 functions, coming from the LLD linker.This doesn't happen while building fluidsynth normally (per their wiki) with the same config flags that juicysfplugin uses. This is probably unrelated to the libpcre2 problem which was discovered and fixed here, because the functions indicated by the errors seem more related to threads and memory than regex.
Relevant excerpt of the console output starting at the compile step that spawns the errors: excerpt.txt
Solutions I've tried include trying to install libglib2.0-dev on the relevant docker images by editing the dockerfile and sh files, changing CMAKE_FIND_ROOT_PATH_MODE variables in [arch]_toolchain.make, trying to install all the fluidsynth dependencies via the dockerfile. A potential solution may be to try using the posix version of mingw, but I'm unsure how to get that working in Docker.
I know the maintainer uses OSX to develop, so I urge anybody reading this who uses a Windows machine to try to replicate it. So far myself and one other person have gotten these same errors.