Open c0d3h4x0r opened 4 years ago
I don't get this error on my end.
Which version of gcc are you using?
Also, when did you last build from clean?
I've asked @Alcaro and I think we came to the consensus that we might as well drop the static assert.
https://github.com/libretro/RetroArch/commit/212f32e2fd9410fc4a5a52e46bd75f4bb75f36da
Try to see if this compiles for you now.
Yeah, just noticed you removed them. Trying another build...
That fixed the static asserts, but I still get all the other errors listed herein.
Looks to me like they are all caused by the inability of the compiler to recognize the _Inout_opt_bytecount_
SAL annotation.
Can you show the current compilation error log?
And I suspect that's due to d3d11.h
neglecting to #include "sal.h"
(or something similar?).
Actually, it looks like d3d11.h
expects rpcsal.h
to have been included, and asserts that it is the correct version... but rpcsal.h
does not define _Inout_opt_bytecount_
.
Can you try getting it building on your end and then sending a PR? I can unfortunately not reproduce your issue here on Msys2 and GCC 9.2.0. It might well be that we need some header includes that are missing right now which for whatever reason are not an issue on my system locally.
Yep, already working on it. I assume that modifying d3d11.h
itself is not advised, given that it looks to be supplied by the DirectX SDK and this codebase presumably doesn't want to fork it.
Do you have sal.h
somewhere in your source tree or include path? Because I don't see it anywhere in the repo, and it is what would normally define _Inout_opt_bytecount_
.
Found this header in another project someplace; seems relevant?
https://github.com/bkaradzic/bx/blob/master/include/compat/mingw/salieri.h
Looks like it originates from here: https://github.com/nemequ/salieri
sal.h should be shipped with your compiler, but if yours doesn't implement or define away _Inout_optbytecount (mine, gcc 8.1.0 via mingw-w64, does not), then I agree salieri seems like a good solution.
I have no clue why any of this ever worked for anyone. static_assert is a C11/C++11 thing, we're not using that.
Actually, it looks like dxgi_common.h
is just missing a define for this.
Also noticed this in dxgi_common.h
, which may apply to your conundrum re: static_assert
:
#ifndef __cplusplus
#define static_assert _Static_assert
#endif
This is all wrapped inside an #ifdef __MINGW32__
check. Is the 64-bit MSYS2-based Windows build supposed to be a MINGW32 build?
I've been building using the command make DEBUG=1 GL_DEBUG=1 -j8
. Should I have instead been running retroarch-mingw-build.sh
? If so, the documentation for building RetroArch (at https://docs.libretro.com/development/retroarch/compilation/windows/ ) did not steer me toward running that script.
Regardless, supposedly the mingw compiler itself is supposed to define __MINGW32__
, but that is clearly not defined as expected.
So apparently the correct command to build debug bits using the correct version of the compiler toolchain should actually be something more like this:
C_COMPILER=/mingw64/bin/x86_64-w64-mingw32-gcc CXX_COMPILER=/mingw64/bin/x86_64-w64-mingw32-g++ WINDRES=/mingw64/bin/x86_64-w64-mingw32-windres /mingw64/bin/mingw32-make DEBUG=1 GL_DEBUG=1 -j8
That actually uses gcc 9.2.0 rather than 9.1.0 (which is what's located at /usr/bin/gcc
in my MSYS2 shell).
But that still doesn't cause __MINGW32__
to get defined like I'd expect. Still trying to figure out why.
I finally figured out what's been causing all my problems.
This one line of the documentation is too vague:
Start the MINGW64 or the MINGW32 shell depending on what you want to compile
I had been launching my shell via win32env.cmd
or msys2_shell.cmd
-- but apparently neither of those are the right way to get a MINGW shell. Apparently I needed to run mingw64.exe
to launch the right shell. After doing that and rerunning ./configure
and make clean
, my build finally appears to be working.
The documentation really needs to be updated to call out that subtle but very important distinction. As a sanity check, the developer should run uname -s
to validate that it says their shell is MINGW-based.
I ran into this same issue. All I needed to do to get past this was close the 32-bit MSYS2 shell and open the 64-bit MSYS2 shell. It is not helpful that the MSYS2 window doesn't say which shell it is in the title bar. The icons have slightly different colors but that doesn't help if you haven't memorized them and you're totally out of luck if you're colorblind.
This documentation should probably also take the Cg dependency out. nvidia have discontinued Cg
Version/Commit
master @ a8a2294f276c7912dc399bd7d4d8611e14b26a17
Environment information
Error output: