Cannot build MAME on Windows MSYS2

jotd666 commented 4 weeks ago

MAME version

0.263

System information

Windows 11 64 bit

INI configuration details

No response

Emulated system/software

No response

Incorrect behaviour

after following the instructions on mamedev site, getting all pacman packages and all, I can run "make" but, after having successfully generated some files, it stops with

$ make GCC 13.3.0 detected cannot open k:/repos/mame/genie.lua: No such file or directory stack traceback: [C]: in upvalue 'builtin_dofile' [string "premake = { }..."]:109: in function 'dofile' [string "_WORKING_DIR = os.getcwd()..."]:46: in function '_premake_main' make: *** [makefile:1119: build/projects/windows/mame/gmake-mingw64-gcc/Makefile] Error 1

genie.lua is not in the root directory, there are copies in "scripts" and somewhere else but not there. MINGW64 is set properly to /mingw64, MINGW32 is not set. It should probably open it from "scripts" but doesn't.

Expected behaviour

MAME should build without issues, as I'm following the exact instructions and downloaded all packages

Steps to reproduce

open MSYS2 clone repository install all recommended packages set MINGW32 to "" and MINGW64 to /mingw64 run "make"

Additional details

No response

angelosa commented 4 weeks ago

What the path variable says when you are in the MSYS2 env and on normal command line? Windows tends to fumble that up, if for example there are spaces in any filename symbol ...

jotd666 commented 4 weeks ago

Thanks for replying. I know spaces and unix don't mix

Copy/paste of the error (first build phases aren't redone, including what it seems like a version of lua, they work):

@.*** MSYS /c/DATA/jff/data/amiga_git_repos/mame $ make GCC 13.3.0 detected cannot open c:/DATA/jff/data/amiga_git_repos/mame/genie.lua: No such file or directory

So my root repository is " /c/DATA/jff/data/amiga_git_repos/mame". No space, no weirdness, ...

Le lun. 3 juin 2024 à 23:45, Angelo Salese @.***> a écrit :

What the path variable says when you are in the MSYS2 env and on normal command line? Windows tends to fumble that up, if for example there are spaces in any filename symbol ...

— Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/12438#issuecomment-2146179607, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD54CEWG54Z22X7CBYOO52DZFTPYRAVCNFSM6AAAAABIXJL2K6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBWGE3TSNRQG4 . You are receiving this because you authored the thread.Message ID: @.***>

angelosa commented 3 weeks ago

fwiw under a Windows environment I do two things:

I don't like the internal MSYS2 shell, so I generally use command prompt around cmd.exe /k <msys2_directory>\win32\env.bat
In turn have to edit env.bat, because the original file from mame-essentials package is essentially outdated by now, cfr. attached file and how I set up PATH to avoid the space fumble as mentioned earlier. env.zip

jotd666 commented 3 weeks ago

sorry, doesn't help, or even start any bash command...

I've found that line 1119 of the makefile tries to run genie. When I do it manually I get this:

$ 3rdparty/genie/bin/windows/genie.exe --distro=generic --with-emulator --OPTIMIZE=3 --target='mame' --subtarget='mame' --build-dir='build' --osd='windows' --targetos='windows' --PLATFORM='x86' --gcc=mingw64-gcc --gcc_version=13.3.0 gmake cannot open k:/jff/data/amiga_git_repos/mame/genie.lua: No such file or directory stack traceback: [C]: in upvalue 'builtin_dofile' [string "premake = { }..."]:109: in function 'dofile' [string "_WORKING_DIR = os.getcwd()..."]:46: in function '_premake_main'

(which is the exact same error as in the makefile). There are several .lua files scattered in the MAME repository but none at the root of the repository. Trying to change directory also fails (it's obviously done to start from repository root). Copying lua file works but then it searches for another one. I've tried setting LUA_PATH to no avail...

Le jeu. 6 juin 2024 à 00:56, Angelo Salese @.***> a écrit :

fwiw under a Windows environment I do two things:

I don't like the internal MSYS2 shell, so I generally use command prompt around cmd.exe /k \win32\env.bat

In turn have to edit env.bat, because the original file from mame-essentials package https://github.com/mamedev/buildtools/blob/master/mame-essentials/src/opt/mamedev/env.bat is essentially outdated by now, cfr. attached file and how I set up PATH to avoid the space fumble as mentioned earlier. env.zip https://github.com/user-attachments/files/15597483/env.zip

— Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/12438#issuecomment-2151094074, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD54CEXV23L3VFGPDWMA4R3ZF6JTFAVCNFSM6AAAAABIXJL2K6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJRGA4TIMBXGQ . You are receiving this because you authored the thread.Message ID: @.***>

pmackinlay commented 3 weeks ago

You don't need a bash command, just a regular Windows command prompt with the env.bat script to set up the environment. Then make sure you change your current directory to the root folder of the repo and make. Please do that and share the results. Similar to @angelosa, I personally add the following to the default env.bat (to use clang instead of gcc, and also to use the llvm ar/ld, which are much faster than the gnu ar/ld on Windows):

@set OVERRIDE_AR=llvm-ar
@set OVERRIDE_CC=clang
@set OVERRIDE_CXX=clang++
@set ARCHOPTS=-fuse-ld=lld
@set MODERN_WIN_API=1

jotd666 commented 3 weeks ago

Thanks but I don't think that this is the real issue. The fact that the "genie.exe" program is looking for a .lua script at a wrong location has probably nothing to do with the setup.

My WSL2 install is a mess, so I'll try building on a Raspberry Pi, see what happens on a real OS...

Le ven. 7 juin 2024 à 05:19, Patrick Mackinlay @.***> a écrit :

You don't need a bash command, just a regular Windows command prompt with the env.bat script to set up the environment. Then make sure you change your current directory to the root folder of the repo and make. Please do that and share the results. Similar to @angelosa https://github.com/angelosa, I personally add the following to the default env.bat (to use clang instead of gcc, and also to use the llvm ar/ld, which are much faster than the gnu ar/ld on Windows):

@set OVERRIDE_AR=llvm-ar @set OVERRIDE_CC=clang @set OVERRIDE_CXX=clang++ @set ARCHOPTS=-fuse-ld=lld @set MODERN_WIN_API=1

— Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/12438#issuecomment-2153775299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD54CEWP5OC2M44UTHDUIBLZGERCPAVCNFSM6AAAAABIXJL2K6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJTG43TKMRZHE . You are receiving this because you authored the thread.Message ID: @.***>

pmackinlay commented 3 weeks ago

The fact it works for others means it has everything to do with your setup. Feel free to share the symptoms after trying what I suggested if you're serious about resolving the issue.

jotd666 commented 3 weeks ago

I dug it a little further

the executable "genie.exe" seems to look for a .lua script. Here's what's interesting:

$ 3rdparty/genie/bin/windows/genie.exe cannot open c:/msys64/home/jotd6/repos/mame/genie.lua: No such file or directory stack traceback: [C]: in upvalue 'builtin_dofile' [string "premake = { }..."]:109: in function 'dofile' [string "_WORKING_DIR = os.getcwd()..."]:46: in function '_premake_main'

=> genie.lua searched in the wrong location, like in the makefile

Now entering in "3rdparty" directory

@.*** MSYS ~/repos/mame $ cd 3rdparty/

@.*** MSYS ~/repos/mame/3rdparty $ genie/bin/windows/genie.exe c:/msys64/home/jotd6/repos/mame/scripts/genie.lua:19: attempt to concatenate a nil value (field 'build-dir')

Now the .lua script is found in "scripts" (and I didn't provide arguments, but it doesn't matter). Somehow the executable can't seem to locate the root dir or whatever depending on the current dir. The logic currently escapes me...

Le sam. 8 juin 2024 à 13:04, Patrick Mackinlay @.***> a écrit :

The fact it works for others means it has everything to do with your setup. Feel free to share the symptoms after trying what I suggested if you're serious about resolving the issue.

— Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/12438#issuecomment-2155990632, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD54CERKR4CFS6BS7KCKY5LZGLQLVAVCNFSM6AAAAABIXJL2K6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJVHE4TANRTGI . You are receiving this because you authored the thread.Message ID: @.***>

jotd666 commented 3 weeks ago

Note that I also tried with windows command prompt following what @angelosa explained

put win32 and etc in msys root
upgraded env.bat
had to remove my %PATH% from ADD_PATH=%PATH% as it had some spaces or stuff in it that made it too long or something. I think this isn't useful in a general case, as mingw paths should be the ones used.

Now:

C:\msys64\win32>cmd /k env.bat [MINGW64] C:\msys64\win32>cd ..

[MINGW64] C:\msys64>make make: *** No targets specified and no makefile found. Stop.

[MINGW64] C:\msys64>cd home\jotd6

[MINGW64] C:\msys64\home\jotd6>dir

[MINGW64] C:\msys64\home\jotd6>cd repos [MINGW64] C:\msys64\home\jotd6\repos>cd mame

[MINGW64] C:\msys64\home\jotd6\repos\mame>make GCC 14.1.0 detected 3rdparty/genie/bin/windows/genie.exe --distro=generic --AR='"llvm-ar"' --with-emulator --OPTIMIZE=3 --ARCHOPTS='"-fuse-ld=lld"' --target='mame' --subtarget='mame' --build-dir='build' --PYTHON_EXECUTABLE='C:\msys64\mingw64\bin\python.exe' --osd='windows' --targetos='windows' --PLATFORM='x86' --gcc=mingw64-gcc --gcc_version=14.1.0 gmake cannot open c:/msys64/home/jotd6/repos/mame/genie.lua: No such file or directory stack traceback: [C]: in upvalue 'builtin_dofile' [string "premake = { }..."]:109: in function 'dofile' [string "_WORKING_DIR = os.getcwd()..."]:46: in function '_premake_main' makefile:1119: recipe for target 'build/projects/windows/mame/gmake-mingw64-gcc/Makefile' failed make: *** [build/projects/windows/mame/gmake-mingw64-gcc/Makefile] Error 1

same bloody error! Looks like a lua bug or something...

cuavas commented 3 weeks ago

Please take this to a discussion forum. It evidently is possible to build with an MSYS64 MinGW environment as multiple developers do it every day, I somehow manage to build releases every month, and the GitHub Actions CI tasks for 64-bit Windows builds work. The issue is with your environment.

jotd666 commented 3 weeks ago

Confirming that it could be a lua issue, as I cleaned everything, after that GCC was in version 14 (it was 13 before, why??) and then it could get past the genie stage now that lua was compiled with gcc 14... !! It's based on the one @angelosa included, with some changed (where I annotated with "JOTD" if it interests someone.

Now there was llvm override, but I'm going to try without that. FYI here's the "env.bat" script I'm using

:: Find root dir @if not defined MSYS2_ROOT ( for /f %%i in ("%~dp0..") do @set MSYS2_ROOT=%%~fi )

:: Add aliases @doskey /macrofile="%MSYS2_ROOT%\win32\aliases"

@set MINGW32= @set MINGW64= rem JOTD: removed windows PATH as 1) it's useless and 2) I get conflicts with java shit or "common files" spaces in path, I dunno @set ADD_PATH= @set PATH=C:\Windows\System32;C:\Windows :: Enhance Path @if "%CONFIG_ARCHITECTURE%"=="x86" ( @set MINGW32=%MSYS2_ROOT%\mingw32 @set MINGW=%MSYS2_ROOT%\mingw32 @set prompt=[MINGW32] $p$g ) else ( @set MINGW64=%MSYS2_ROOT%\mingw64 @set MINGW=%MSYS2_ROOT%\mingw64 @set ARCHOPTS="-fuse-ld=lld" rem @set OVERRIDE_AR="llvm-ar" JOTD: removed that override to use standard ar @set prompt=[MINGW64] $p$g ) @if not defined VS_DISABLE ( @if defined VS120COMNTOOLS ( @call "%VS120COMNTOOLS%vsvars32.bat" ) @if defined VS140COMNTOOLS ( @call "%VS140COMNTOOLS%vsvars32.bat" ) ) @set MINGW_PATH=%MINGW%\bin

@IF EXIST "%MSYS2_ROOT%\vendor\python" ( @set ADD_PATH=%MSYS2_ROOT%\vendor\python;%MSYS2_ROOT%\vendor\python\Scripts;%ADD_PATH% ) @IF EXIST "%MSYS2_ROOT%\vendor\nodejs" ( @set ADD_PATH=%appdata%\npm;%MSYS2_ROOT%\vendor\nodejs;%ADD_PATH% ) @IF EXIST "%MSYS2_ROOT%\vendor\android-ndk" ( @set ADD_PATH=%MSYS2_ROOT%\vendor\android-ndk;%ADD_PATH% @set ANDROID_NDK_ROOT=%MSYS2_ROOT%\vendor\android-ndk @set ANDROID_NDK_LLVM=%MSYS2_ROOT%\vendor\android-ndk\toolchains\llvm\prebuilt\windows-x86_64 @set ANDROID_NDK_ARM=%MSYS2_ROOT%\vendor\android-ndk\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64 @set ANDROID_NDK_ARM64=%MSYS2_ROOT%\vendor\android-ndk\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64 @set ANDROID_NDK_MIPS=%MSYS2_ROOT%\vendor\android-ndk\toolchains\mipsel-linux-android-4.9\prebuilt\windows-x86_64 @set ANDROID_NDK_MIPS64=%MSYS2_ROOT%\vendor\android-ndk\toolchains\mips64el-linux-android-4.9\prebuilt\windows-x86_64 @set ANDROID_NDK_X86=%MSYS2_ROOT%\vendor\android-ndk\toolchains\x86-4.9\prebuilt\windows-x86_64 @set ANDROID_NDK_X64=%MSYS2_ROOT%\vendor\android-ndk\toolchains\x86_64-4.9\prebuilt\windows-x86_64 ) @IF EXIST "%MSYS2_ROOT%\vendor\emsdk" ( @IF NOT EXIST "%USERPROFILE%.emscripten" ( @echo Creating file .emscripten @call "%MSYS2_ROOT%\vendor\emsdk\emsdk.bat" activate > nul ) @set EMSCRIPTEN=%MSYS2_ROOT%\vendor\emsdk\emscripten\1.35.0 @call "%MSYS2_ROOT%\vendor\emsdk\emsdk.bat" construct_env > nul ) @IF EXIST "%MSYS2_ROOT%\vendor\nacl_sdk" ( @set NACL_SDK_ROOT=%MSYS2_ROOT%\vendor\nacl_sdk\pepper_47 @set CYGWIN=nodosfilewarning ) @IF EXIST "%MSYS2_ROOT%\vendor\java" ( @set JAVA_HOME=%MSYS2_ROOT%\vendor\java ) @IF EXIST "%MSYS2_ROOT%\vendor\android-sdk" ( @set ANDROID_HOME=%MSYS2_ROOT%\vendor\android-sdk )

@set PATH=%ADD_PATH%;%MSYS2_ROOT%\win32;%MINGW_PATH%;%MSYS2_ROOT%\usr\bin;%PATH%

@set PYTHON_EXECUTABLE=%MINGW%\bin\python.exe @if not exist "%MSYS2_ROOT%\home" ( @bash --login /dev/null ) :: @bash --login /init.sh

Pretty touchy!!

mamedev / mame