Missing files on install (windows)

[amerika13]

Our team has a working build system with ngdevkit. However, when setting up my environment to do builds, the neo geo build of our game is failing for me. After troubleshooting with another person who has it working, we have found some differences in his setup versus mine. So there might be something incorrect about the install steps for Windows.

My z80-neogeo-ihx\bin directory has sdobjectcopy.exe, but if I try --version, I get an error. Our working setup has zlib1.dll in that directory. However, if I copy zlib1.dll to z80-neogeo-ihx\bin from the UCRT64\bin dir, I no longer get that error and the build moves on a bit further before receiving another error.

At that point a ran --version on all executables. Running sdcc.exe --version, I get an error stating that libgcc_s_seh-1.dll was not found. Then libstdc++-6.dll was not found. Then libwinpthread-1.dll. I copied all of these from UCRT64\bin dir.

However, this did not fix my build issue. Is there more things missing than just the few .dll files in the C:\msys64\ucrt64\z80-neogeo-ihx\bin?

I ask because the working setup has a lot more files than I have.

Thank you.

[dciabrin]

Let me try locally on a msys2 env to try to replicate.
Can you be more specific re. your working env? Is it using nightly msys2 packages, or did you build th devkit yourself in that env? If the former, can you give me the name and version of the installed packages?
I changed the way i build the packages on MSYS2 a while ago to switch from mingw64 to ucrt64, maybe that's related.

[amerika13]

I installed it via pre-built binary that is located in the MSYS2 setup instructions. I downloaded it and installed it with default settings. It installed everything, including UCRT64. I've only been using UCRT64 as the ngdevkit instructions state that is the only supported way now.

https://github.com/msys2/msys2-installer/releases/download/2025-02-21/msys2-x86_64-20250221.exe is the URL I used. I did not try to see if there was an updated package beyond that.

[dciabrin]

OK I'm restarting my env as we speak, I'll upgrade my env with pacman and report back shortly

[dciabrin]

I just upgraded my MSYS2 env to the most recent nighlt package of ngdevkit with:

# Upgrade system, ngdevkit, allow overwrite current ngdevkit files on disk
pacman -Syyu mingw-w64-ucrt-x86_64-ngdevkit --overwrite "*" 

This is the version that got picked up:

# pacman -Q | grep ngdevkit
mingw-w64-ucrt-x86_64-ngdevkit 0.4+202506080819-1
mingw-w64-ucrt-x86_64-ngdevkit-gngeo 0.8.1+202501101116-1
mingw-w64-ucrt-x86_64-ngdevkit-toolchain 0.1+202502202107-1

With that, I can run e.g. sdobjcopy as expected:

# /ucrt64/z80-neogeo-ihx/bin/sdobjcopy.exe --version
GNU objcopy (sdbinutils derived from GNU Binutils) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

I'm running bash in the UCRT environment. Can you maybe check if your env needs to be upgraded?

[amerika13]

ameri@Obsidian UCRT64 ~
$ pacman -Q | grep ngdevkit
mingw-w64-ucrt-x86_64-ngdevkit 0.4+202506080819-1
mingw-w64-ucrt-x86_64-ngdevkit-gngeo 0.8.1+202501101116-1
mingw-w64-ucrt-x86_64-ngdevkit-toolchain 0.1+202502202107-1

I just ran the same upgrade you did, and if i don't have the .dll files i mentioned in that directory, sdobjcopy.exe does not function.

When you say check if my env needs to be upgrade, what exactly do you mean? Excuse my ignorance, I am new to MSYS2.

To me this feels like I have a path/environment variable issue. I was told to setup an env variable by the person who has this working, but my issues happen if I have that set or not. He verified I did it correctly as well.

[dciabrin]

Ok i might have an idea. For reference, I start my MSYS2 env from a regular cmd.exe as follows:

set MSYSTEM=UCRT64
C:\msys64\usr\bin\bash.exe -l

Once I'm in bash, the proper UCRT should be the proper MSYS2 variant (your prompt seem to say the same).

# env | grep MSYS
MSYSTEM=UCRT64
MSYSTEM_CARCH=x86_64
MSYSTEM_CHOST=x86_64-w64-mingw32
PS1=\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[35m\]$MSYSTEM\[\e[0m\] \[\e[33m\]\w\[\e[0m\]\n\[\e[1m\]#\[\e[0m\] 
MSYSTEM_PREFIX=/ucrt64

Now if I check sdobjcopy, on my system it finds zlib in the default directory:

# ldd /ucrt64/z80-neogeo-ihx/bin/sdobjcopy.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff9ca890000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff9c8a60000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff9c81d0000)
        ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ff9c80d0000)
        USER32.dll => /c/Windows/System32/USER32.dll (0x7ff9c9f80000)
        win32u.dll => /c/Windows/System32/win32u.dll (0x7ff9c80a0000)
        GDI32.dll => /c/Windows/System32/GDI32.dll (0x7ff9ca820000)
        gdi32full.dll => /c/Windows/System32/gdi32full.dll (0x7ff9c7f80000)
        msvcp_win.dll => /c/Windows/System32/msvcp_win.dll (0x7ff9c8580000)
        zlib1.dll => /ucrt64/bin/zlib1.dll (0x7ff9bba20000)

This comes from mingw-w64-ucrt-x86_64-zlib if i'm not mistaken, and this is a dependency of package ngdevkit-toolchain, so it should have been installed automatically.

Could you check whether you have zlib1.dll under /ucrt64/bin, and if not whether you have mingw-w64-ucrt-x86_64-zlib installed?

[amerika13]

c:\msys64\usr\bin>bash.exe -l

ameri@Obsidian UCRT64 ~
$ env | grep MSYS
MSYSTEM=UCRT64
MSYSTEM_CARCH=x86_64
MSYS2_PATH=/usr/local/bin:/usr/bin:/bin
MSYSTEM_CHOST=x86_64-w64-mingw32
PS1=\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[35m\]$MSYSTEM\[\e[0m\] \[\e[33m\]\w\[\e[0m\]\n\$
MSYSTEM_PREFIX=/ucrt64

ameri@Obsidian UCRT64 ~
$ ldd /ucrt64/z80-neogeo-ihx/bin/sdobjcopy.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffb3cf60000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffb3b500000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffb3a470000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffb3ab30000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ffb3bb90000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ffb3a230000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ffb3bb60000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ffb3a0f0000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ffb3a900000)
        zlib1.dll => /ucrt64/z80-neogeo-ihx/bin/zlib1.dll (0x7ffb210d0000)

This is what I see on my end when starting up UCRT64 the way you described.

I can confirm that zlib1.dll and other missing .dll files are in the \ucrt64\bin as that is where I copied them from and placed them in the C:\msys64\ucrt64\z80-neogeo-ihx\bin folder.

My question is, should zlib1 and other dlls be in the ucrt64\z80-neogeo-ihx\bin? Or should the executables be looking for them in \ucrt64\bin?

[dciabrin]

My question is, should zlib1 and other dlls be in the ucrt64\z80-neogeo-ihx\bin? Or should the executables be looking for them in \ucrt64\bin?

The dll should all be located in their respective standard location, the executable have no way to tell and the system should make the resolution automatically. I think if this is not the case, chances are your PATH variable is not having /ucrt64/bin in it.

# env | grep PATH
PKG_CONFIG_PATH=/ucrt64/lib/pkgconfig:/ucrt64/share/pkgconfig
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
MANPATH=/ucrt64/local/man:/ucrt64/share/man:/usr/local/man:/usr/share/man:/usr/man:/share/man
ORIGINAL_PATH=/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/
INFOPATH=/ucrt64/local/info:/ucrt64/share/info:/usr/local/info:/usr/share/info:/usr/info:/share/info
ACLOCAL_PATH=/ucrt64/share/aclocal:/usr/share/aclocal
PKG_CONFIG_SYSTEM_LIBRARY_PATH=/ucrt64/lib
HOMEPATH=\Users\dciabrin
PATH=/ucrt64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl     
PKG_CONFIG_SYSTEM_INCLUDE_PATH=/ucrt64/include

Chances are your PATH is incorrect. On my system, starting bash with MSYSTEM=UCRT64 /usr/bin/bash -l forcibly reinitializes PATH and add the right ucrt64 directory into the PATH. Could you check that in your env?