Closed birdybro closed 3 years ago
After many attempts with getting zlib in there, I have no idea how to get this to work in MSVC2019, so I'm going the MSYS2 method, but it still fails in MSYS2:
$ make WINDOWS=1
...
VGMPlay.c:43:10: fatal error: conio.h: No such file or directory
43 | #include <conio.h> // for _inp()
| ^~~~~~~~~
compilation terminated.
make: *** [Makefile:297: obj/VGMPlay.o] Error 1
Apparently conio.h is missing. So I commented out the 3 lines in the master referencing conio.h to see what happens... then I get a zlib.h missing error.
VGMPlay.c:85:10: fatal error: zlib.h: No such file or directory
85 | #include <zlib.h>
| ^~~~~~~~
compilation terminated.
make: *** [Makefile:297: obj/VGMPlay.o] Error 1
Which doesn't make sense since it is actually there, it's just in ~/VGMPlay/zlib, however... in_vgm.c, VGMPlay_AddFmts.c, and VGMPlay.c all have zlib.h included with #include <zlib.h>
which is for implementation dependent method of searching for the header. Changing it to #include "zlib/zlib.h"
yields the following:
Compiling VGMPlay.c ...
VGMPlay.c: In function ‘GetGZFileLengthW’:
VGMPlay.c:1276:10: warning: implicit declaration of function ‘_wfopen’; did you mean ‘_lopen’? [-Wimplicit-function-declaration]
1276 | hFile = _wfopen(FileName, L"rb");
| ^~~~~~~
| _lopen
VGMPlay.c:1276:8: warning: assignment to ‘FILE *’ {aka ‘struct __sFILE64 *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
1276 | hFile = _wfopen(FileName, L"rb");
| ^
Compiling VGMPlay_AddFmts.c ...
Compiling Stream.c ...
Compiling ChipMapper.c ...
Compiling VGMPlayUI.c ...
VGMPlayUI.c: In function ‘main’:
VGMPlayUI.c:560:5: warning: implicit declaration of function ‘_getch’; did you mean ‘_getc_r’? [-Wimplicit-function-declaration]
560 | _getch();
| ^~~~~~
| _getc_r
VGMPlayUI.c:611:11: warning: implicit declaration of function ‘_kbhit’ [-Wimplicit-function-declaration]
611 | while(_kbhit())
| ^~~~~~
VGMPlayUI.c: In function ‘wprintc’:
VGMPlayUI.c:1941:12: warning: implicit declaration of function ‘_vsnwprintf’; did you mean ‘vswprintf’? [-Wimplicit-function-declaration]
1941 | RetVal = _vsnwprintf(printbuf, BufSize - 0x01, format, arg_list);
| ^~~~~~~~~~~
| vswprintf
Compiling mmkeys_Win.c ...
Compiling dbus_stub.c ...
Linking vgmplay ...
/usr/lib/gcc/x86_64-pc-msys/9.3.0/../../../../x86_64-pc-msys/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
make: *** [Makefile:274: vgmplay] Error 1
So is there also a prerequisite that is not being mentioned for MSYS2?
Removed my comment that was about ubuntu install because I was being a dumb :P. I was able to compile on Ubuntu 16.04 succesfully. Will edit my progress on MSVC and MinGW/MSYS2 as I figure those out above.
Let me clear things about zlib up at first:
zlib/
folder (but see notes below)For MSVC in Win32 mode, what works best is to link against zdll.lib
.
Unfortunately the vcxproj seems to link against zlibd.lib
in Win32 Debug mode. (VC6 Win32 Debug, static lib) That definitely doesn't work. (IIRC not even VC2010 was able to link against the VC6 debug build of zlib.)
I'll see if I can fix the project later.
I also included zlib.lib
(VC6 Win32 Release, static lib), which I used for building in_vgm.
I'm very sure that none of the static libs work with VC2015 and higher. (I think they may cause trouble with VC2010 as well, but I don't remember details.)
There are no 64-bit zlib DLLs, so for those, zlibstat64[d].lib
files are included. These are built with MSVC 2010 and will probably not work with VC2015 and higher, sorry.
Thanks for the headsup! It's been a fun learning process personally anyways, so no apologies necessary! :)
As for why MSYS2 fails to find <conio.h>
- no idea. It's a standard Windows header used for all sorts of console functions.
VGMPlayUI.c uses it for _getch
and _kbhit
(keyboard controls).
_inp
isn't used unless you set DISABLE_HWOPL_SUPPORT=0
I'm reinstalling MSYS2 - https://www.msys2.org/ completely to rule out problems on my end, since it was an older configuration. I had made a little progress by manually installing libao, dbus, and headers-git packages that were for msys2 (pacman -s method), but then ran into a huge amount of other errors, then my computer rebooted since I was doing other things, and lost my notes X_X
So anyways, reinstalling again, will report back with what I find.
Possible necessary first step is the make libao dbus and headers packages in msys2 as base msys2 installation does not have these. The names of these packages for reference:
I also installed git just to speed things up on my end in testing. Here's the run I did.
$ pacman -S make mingw-w64-x86_64-libao mingw-w64-x86_64-headers-git mingw-w64-x86_64-dbus git
...
$ git clone https://github.com/vgmrips/vgmplay.git
$ cd vgmplay/VGMPlay
$ make
$ make WINDOWS=1
Compiling chips/262intf.c ...
Compiling chips/2151intf.c ...
Compiling chips/2203intf.c ...
Compiling chips/2413intf.c ...
Compiling chips/2608intf.c ...
Compiling chips/2610intf.c ...
Compiling chips/2612intf.c ...
Compiling chips/3526intf.c ...
Compiling chips/3812intf.c ...
Compiling chips/8950intf.c ...
Compiling chips/adlibemu_opl2.c ...
Compiling chips/adlibemu_opl3.c ...
Compiling chips/ay8910.c ...
Compiling chips/ay_intf.c ...
Compiling chips/c140.c ...
Compiling chips/c352.c ...
Compiling chips/c6280.c ...
Compiling chips/c6280intf.c ...
Compiling chips/dac_control.c ...
Compiling chips/es5503.c ...
Compiling chips/es5506.c ...
Compiling chips/emu2149.c ...
Compiling chips/emu2413.c ...
Compiling chips/fm2612.c ...
Compiling chips/fm.c ...
Compiling chips/fmopl.c ...
Compiling chips/gb.c ...
Compiling chips/iremga20.c ...
Compiling chips/k051649.c ...
Compiling chips/k053260.c ...
Compiling chips/k054539.c ...
Compiling chips/multipcm.c ...
Compiling chips/nes_apu.c ...
Compiling chips/nes_intf.c ...
Compiling chips/np_nes_apu.c ...
Compiling chips/np_nes_dmc.c ...
Compiling chips/np_nes_fds.c ...
Compiling chips/okim6258.c ...
Compiling chips/okim6295.c ...
Compiling chips/Ootake_PSG.c ...
Compiling chips/opll.c ...
Compiling chips/opm.c ...
Compiling chips/panning.c ...
Compiling chips/pokey.c ...
Compiling chips/pwm.c ...
Compiling chips/qsound_ctr.c ...
Compiling chips/qsound_mame.c ...
Compiling chips/qsound_intf.c ...
Compiling chips/rf5c68.c ...
Compiling chips/saa1099.c ...
Compiling chips/segapcm.c ...
Compiling chips/scd_pcm.c ...
Compiling chips/scsp.c ...
Compiling chips/scspdsp.c ...
Compiling chips/sn76489.c ...
Compiling chips/sn76496.c ...
Compiling chips/sn764intf.c ...
Compiling chips/upd7759.c ...
Compiling chips/vsu.c ...
Compiling chips/ws_audio.c ...
Compiling chips/x1_010.c ...
Compiling chips/ym2151.c ...
Compiling chips/ym2413.c ...
Compiling chips/ym2612.c ...
Compiling chips/ym3438.c ...
Compiling chips/ymdeltat.c ...
Compiling chips/ymf262.c ...
Compiling chips/ymf271.c ...
Compiling chips/ymf278b.c ...
Compiling chips/ymz280b.c ...
Compiling chips/ay8910_opl.c ...
Compiling chips/sn76496_opl.c ...
Compiling chips/ym2413hd.c ...
Compiling chips/ym2413_opl.c ...
Compiling VGMPlay.c ...
VGMPlay.c:43:10: fatal error: conio.h: No such file or directory
43 | #include <conio.h> // for _inp()
| ^~~~~~~~~
compilation terminated.
make: *** [Makefile:297: obj/VGMPlay.o] Error 1
MSYS2 by default includes their include folders into the environment variables already, so I'm not sure why it can't find it when conio.h is specifically already there :P
you shouldn't need to mess too much with packages, just make sure you install the correct versions (prefixed with mingw-w64-x86_64
etc, you can run pacman -Ss <package name>
to search for a package and check which versions are available. Build vgmplay with make WINDOWS=1
. You don't need dbus or libao for Windows builds.
Okay, I removed libao and dbus. conio.h same error still there. Important to note, if I remove the headers-git package, also the same error. So maybe the mingw-w64-x86_64-headers-git headers as installed need an PATH environment variable configured within MSYS2's console? hrmm...
Okay, reinstalled mingw-w64-x86_64-headers-git package, added to MSYS2 PATH with export C_INCLUDE_PATH='C:\msys64\mingw64\x86_64-w64-mingw32\include'
just to rule out PATH issue, not seeing conio.h and...
Well there were a ton of errors which I assume are due to these being 64-bit headers or due to a mismatch between microsoft's conio.h and borland's conio.h? Either way I tried mingw32.exe's console instead to rule out some stuff, same error.
So essentially the error is it can't find conio.h, and when i force it to see it, it doesn't like it. :P
Keep in mind that you should launch MSYS2 using the "MSYS2 MinGW-w64 x86-64" shortcut in order for it to detect the proper toolchain. This includes the includes folder as well as libraries.
The Visual Studio projects should be fixed with fb3a72d37b7e515e800eddbe776a17a3531cfa8b.
@birdybro please test and close the issue if it works.
Yup it works! Thanks!
Summary
The current build instructions do not list a key prerequisite and this causes current MSVC versions to fail compiling later builds. Given that there have been no new releases since 2018 and significant changes have happened since then, the readme ought to be updated to reflect this common difficulty many will have (since I doubt most people are using MSVC 6.0 in 2020, the software is not free and the installation process on Windows 10 is a nightmare --> https://www.codeproject.com/Articles/1191047/Install-Visual-Studio-on-Windows).
Errors/attempts
Version used: latest commit as of today --> https://github.com/vgmrips/vgmplay/commit/ead5e589d2aa9fbf5bc470eb9ab8795ef455440e
I tried both methods that were provided to me by the readme as is. Upon opening it says the 2010 build tools cannot be located. I did two tests, running it without upgrading the build tools configuration, and running it with upgrading the build tools configuration (as the prompt from MSVC2019 told me I should). Each time I unzipped a fresh folder to be sure that it was a fresh run. Here's the logs from each:
Just running "build solution" after loading the vcprojx file as instructed like normal:
With the build being upgraded as prompted by MSVC2019:
So the first error indicated I need to upgrade the project to be able to build it. So I did that next time, and the errors I got showed 2 linker errors (LNK2019 - https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2019?f1url=%3FappId%3DDev16IDEF1%26l%3DEN-US%26k%3Dk(LNK2019)%26rd%3Dtrue&view=msvc-160) and 2 unresolved externals (LNK1120 - https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk1120?f1url=%3FappId%3DDev16IDEF1%26l%3DEN-US%26k%3Dk(LNK1120)%26rd%3Dtrue&view=msvc-160).
I have all of the MS VC redistributals from the chocolatey vcredist-all package which should cover all those bases. I'm now downloading and installing the Win7 SDK (https://www.microsoft.com/en-us/download/details.aspx?id=8279) just to cover my bases... and I got the same errors. Looking through the issues yields this identical problem to mine:
https://github.com/vgmrips/vgmplay/issues/44
The compilation instructions do not list zlib as a prerequisite, or any prerequisites, which can unnecessarily lead to confusion.
I'll now attempt to, as those instructions point out, compile zlib on windows 10 for use in MSVC2019 to see if I can get anywhere. If I do, I'll report back.