Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails to build on 64-bit mingw with gcc 5.3.0 #169

Open
jwt27 opened this issue Feb 21, 2016 · 12 comments
Open

Fails to build on 64-bit mingw with gcc 5.3.0 #169

jwt27 opened this issue Feb 21, 2016 · 12 comments

Comments

@jwt27
Copy link
Contributor

jwt27 commented Feb 21, 2016

Continued from #164: I'm trying to build DOSBox-X on gcc 5.3.0 under 64-bit mingw (msys2), but it fails.
Installed the dependencies (SDL etc) through pacman, then configured with ./configure --build=x86_64-w64-mingw32 --disable-shaders.
Here's the full output from make -k: https://gist.github.com/jwt27/f43a2b90b1dbe343a671

Most are narrowing conversion errors but there are a few others. I think I can fix most of these but I'm not sure what to do in direct3d.h with the duplicate definitions.

@joncampbell123
Copy link
Owner

I'm starting to think some of the issues you're seeing are related to the code that assumes Microsoft C++ if it sees the WIN32 define. I'm also confused why mingw doesn't recognize the %zu printf format specifier? %zu means you're printing a size_t value.

@sikthehedgehog
Copy link

Is it using the old MSVCRT for that function? I would guess that one doesn't know about %zu.

@jwt27
Copy link
Contributor Author

jwt27 commented Feb 21, 2016

Is %zu a C++11 feature? I noticed configure says checking checking for C++11 support... checking whether g++ accepts " -std=gnu++11 "... no, which seems wrong.

edit: it's using -std=gnu++0x instead. nevermind then. Still gnu++11 should work too.

@sikthehedgehog
Copy link

I think %zu may be there in C99 already, it's just that the DLL in question wasn't exactly up to date with even C99 as far as I know. So the question here is whether MinGW is using that or its own implementation. (also just to make it clear: are we talking about MinGW or MinGW-w64? because the former definitely uses that old MSVCRT DLL and is horribly unmaintained overall)

EDIT: nevermind just saw it's MinGW-w64. Move on.

@joncampbell123
Copy link
Owner

%zu is the printf format for size_t, at least in Linux.

Unfortunately mingw compiles against MSVCRT.DLL which doesn't support that.

@joncampbell123
Copy link
Owner

Are you able to compile the latest code?

I will close this issue if it is no longer a problem.

@jwt27
Copy link
Contributor Author

jwt27 commented Aug 31, 2018

I'll have to try. master branch?

@joncampbell123
Copy link
Owner

Yup.

@jwt27
Copy link
Contributor Author

jwt27 commented Aug 31, 2018

I ran ./build-mingw and got a working executable. Now I see there's an SDL2 version... will have to check that one too.

Build log here: https://gist.github.com/jwt27/45d0698d7c0c0de4b7f352297c7abf96

@jwt27
Copy link
Contributor Author

jwt27 commented Aug 31, 2018

./build-mingw-sdl2 fails on linking the executable. I'm probably missing some prerequisites, although I have all available SDL2 packages installed.

Build log: https://gist.github.com/jwt27/cf3ebeba3378d15d04e933c65b40224e

@joncampbell123
Copy link
Owner

The official MinGW (not MinGW64) binaries seem to have intermittent problems with compiling properly, whether or not -j is used, at least on Windows 10.

Running the build script again might allow the compile to work properly.

@joncampbell123
Copy link
Owner

One obvious sign it's going to fail in this way is if the console output intermittently jumbles the character output during compile, it seems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants