Problems when building bsnes-plus with msys2 about bsnes-plus HOT 8 CLOSED

1. If you're going to build on Windows, I recommend invoking mingw32-make from the normal Windows command line; bsnes' makefiles expect either Windows, or a POSIX-compatible environment, but not really both at the same time (which is what you get with msys2). They could eventually be rewritten to support msys2 but it's not really a priority.

2. as mentioned in the readme, Qt's bin directory needs to be in your PATH; the makefile will use that to locate headers/libs. If it was already in your path then it might have also been a msys2 issue

3. dllexport is only ever (meaningfully) defined when _WIN32 is defined, and expands to an empty string on all other platforms (which is a pretty common way to declare DLL exports). If __declspec(dllexport) caused a build error then I suspect that was also msys2's problem.

from bsnes-plus.

2. It's not a msys2 issue. Certainly Qt's bin is in my path, then the makefile suppose that Qt's include`` is inQt_bin/../include```, which is not always correct. You don't suppose so on linux, do you?
3. It's a problem of msys2 because other platform have no such a problem? Msys2 is only a posix environment, whose g++ package target mingw too

Carter Li@CarterLi-PC MINGW64 /d/work/bsnes-plus/snesfilter
$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.9.2/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --with-gxx-include-dir=/mingw64/include/c++/4.9.2 --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-cloog-backend=isl --enable-version-specific-runtime-libs --disable-cloog-version-check --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-cloog=/mingw64 --with-pkgversion='Rev5, Built by MSYS2 project' --with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.9.2 (Rev5, Built by MSYS2 project)

The problem is:

1. We #define dllexport __declspec(dllexport)
2. Then Qt # define Q_DECL_EXPORT __declspec(dllexport)
3. Which results in # define Q_DECL_EXPORT __declspec(__declspec(dllexport)).
   It has nothing to do with msys2, mingw and g++. It's what our code does.

As I said before, it's ok not to fix the 1st & 2nd one if we don't care about msys2. At least we should fix the third one by replacing #define dllexport by #define DLLEXPORT or something else. I have no idea why other people have no problem building such code, but it's a problem

from bsnes-plus.

Okay, I see the issue now with dllexport - I had misread the error text earlier and completely missed the part about Qt headers. Now that that's clear, I'm not really sure why that doesn't cause problems on my end either, but I can change bsnes' defines to be more unique later. Thanks for pointing that out.

from bsnes-plus.

Okay, the dllexport conflict should be taken care of. Still not sure how the hell that even managed to compile in the first place.

As for the Qt paths issue - for some reason I had Qt in my path as well (with includes and libs living next to binaries, as the makefile assumes) and they still weren't found when building via msys2 for some reason, so I assumed that might have been the problem. At some point I'll probably update the makefiles to be more friendly with msys2 and pkg-config but I don't really have the time to try to hack on them at the moment.

(also keeping this issue open for now so I don't forget)

from bsnes-plus.

I've had some issues with 2 as well on my Windows system. It seems the problem is that the Makefile is searching for a file "moc.exe" to prove that a path is the location of QT. However, on my system there is also a moc.exe within the bin folder for MinGW.

This is the offending line (line 50 in the Makefile for qt-ui\template):
qtpath := $(foreach path,$(subst ;, ,$(PATH)),$(if $(wildcard $(path)/$(moc).exe),$(path)))

All that needs to be done is to search for a filename that only exists within QT's bin folder.
I just picked one:
qtpath := $(foreach path,$(subst ;, ,$(PATH)),$(if $(wildcard $(path)/qtvars.bat),$(path)))

from bsnes-plus.

Is the moc.exe in MinGW's bin directory something other than Qt's moc?

from bsnes-plus.

It does appear that it was for Qt, but it was a separate Qt installation. I used Win-builds package manager to set up MinGW, which by default included a number of other packages, including Qt. It was Qt5 instead of 4.8.6 though, and some of the file names were different (no QtCore, but QtCore5 was present). Changing the MinGW installation such that the Qt package was not automatically installed with it also fixed the problem.

Edit: It might also be good to point out in the readme that the version of MinGW that you use must be the same as the one that was used to compile the Qt version you are using. I was using a more recent version of MinGW, and I kept running into errors until I figured it out. Various versions of Qt and the MinGW versions used to build them can be found here: https://wiki.qt.io/MinGW

from bsnes-plus.

I finally took time to go through the makefiles and make sure everything still builds fine under msys2, and now it should. I haven't added this to the build instructions but that should happen soon.

from bsnes-plus.