0

My app compiles with the 32-bit version of mingw inside of Windows. I've been trying to cross compile from WSL2 using the 64-bit version of mingw.

Both apps compile, but only the 32-bit version works. The 64-bit executable gives a "The application was unable to start correctly (0xc000007b)" error when trying to run the executable. I've busted out Dependency Walker, and there is a clear difference in how the libraries are loaded.

Screenshot of Dependency Walker on the 64-bit application with the glew library selected and many glfw calls in the Parent Import Function List View

Screenshot of Dependency Walker on the 32-bit application with the glew library selected and no glfw calls in the Parent Import Function List View

The top screenshot is the 64-bit executable and the bottom one is the 32-bit executable.

I'm fairly certain this is the problem, because when I tried to run the application from the Windows "Run" app, it gave the error "The procedure entry point glfwCreateWindow could not be located in the dynamic link library".

In the path environment variables, I have both the 32-bit and the 64-bit libraries for glew and glfw, but the 64-bit ones are searched before the 32-bit ones, and glfw is being searched before glew.

The main problem is that I don't understand why the load-linker is trying to get glew to handle the glfw calls in the 64-bit executable when it's not in the 32-bit executable. I don't really know where to go from here. Any fixes, redirections to duplicate questions, and all reader's time is appreciated!

TheZouave
  • 73
  • 6
  • I'm curious, why do you cross-compile? There are [better MinGW distribtions](https://stackoverflow.com/q/30069830/2752075) available, that run natively on Windows. – HolyBlackCat Aug 19 '23 at 05:30
  • It's an interesting issue, but ultimately you can just place all necessary DLLs directly next to the .exe, since that directory is searched first. Most likely this is how you'll distribute your app to others. – HolyBlackCat Aug 19 '23 at 09:49
  • @HolyBlackCat #2 I'm trying to cross compile because I want to practice using Linux to target Windows. Even something like MSYS2 is a VM running a linux shell, so I might as well use the VM I already have. #3 I'll try that, but the issue doesn't seem to be finding the DLLs, it seems to be linking against them incorrectly at load time. The deeper issue is that I don't know what could cause that. #1 Done – TheZouave Aug 19 '23 at 10:19
  • (3) This error usually means that a wrong dll with the same name is being used, because someone added a different version of it to PATH. It never happens if all DLLs are next to the EXE, because stuff in PATH isn't considered then. The problematic DLL is not necessarily the one mentioned in the error. – HolyBlackCat Aug 19 '23 at 11:06
  • (2) *"practice using Linux to target Windows"* This is a good goal, but be aware that cross-compilation consistently doesn't get much love compared to native, and generally requires more effort to set up. Ubuntu ships an outdated MinGW GCC (especially the stable Ubuntu), and barely ships any prebuilt libraries for it. Some distributions are better at it (Arch, I think). MSYS2 tends to ship up-to-date stuff, and provides a lot of prebuilt libraries. – HolyBlackCat Aug 19 '23 at 11:38
  • I'd recommend one of the distribution-agnostic cross-compilation environments: either [quasi-msys2](https://github.com/HolyBlackCat/quasi-msys2) (which I made; it reuses MSYS2 packages) or [mxe](https://mxe.cc/) (they're rather well-known, build stuff from source, but seem to have less packages, and they're less up-to-date). Those simplify the setup, so you don't have to configure stuff manually (write CMake toolchain files, and all that). – HolyBlackCat Aug 19 '23 at 11:40
  • 1
    *"MSYS2 is a VM running a linux shell"* Nah. Most of their applications (compilers, the rest of the toolchain) are native Windows apps. They use a fork of Cygwin for some utilities not directly related to compilation (bash, the package manager, etc), but it's still not a VM, more like reverse Wine. After you install the packages, you don't have to touch the Cygwin-based stuff anymore, unless your build system needs them (e.g. autotools, or non-trivial handwritten makefiles). – HolyBlackCat Aug 19 '23 at 11:44
  • The 2nd image is irrelevant. To get relevant results you should view the *032bit* executable using a *032bit* *DependencyWalker*. Also don;t mix and match paths for the 2 architectures (where are th *GL* *lib*s?). Might help: [\[SO\]: Discover missing module using command-line ("DLL load failed" error) (@CristiFati's answer)](https://stackoverflow.com/a/74883130/4788546), [\[SO\]: Python Ctypes - loading dll throws OSError: \[WinError 193\] %1 is not a valid Win32 application (@CristiFati's answer)](https://stackoverflow.com/a/57297745/4788546). – CristiFati Aug 21 '23 at 09:47

0 Answers0