Closed Danfun64 closed 2 years ago
The problem is that glitchmain.h is defining a bunch of function names which are not present in a normal windows environment, but they are also being defined by SDL_opengl.h. You can fix this by changing line 73 in glitchmain.h from:
#ifdef _WIN32
to:
#if defined(_WIN32) && !defined (__MSYS__)
I made the change to that file, but I get almost the same result. http://paste.debian.net/989659/
looks like that didn't work at all. Can you run this command from a command-line terminal in your msys environment:
gcc -dM -E - < /dev/null
and then paste the output?
Yeah, for some reason MSYS is not being defined by your compiler. You can make it work by changing that line to this:
#if defined(_WIN32) && !(defined(__MINGW64__) || defined(__MINGW32__))
I don't know if that's the proper fix for this issues in general though; it might cause problems with people on other systems.
Changing the if to remove references to msys and adding the mingw references results in this: http://paste.debian.net/989687/
Out of curiosity, I copied that string you posted to line 139 and well and got this: http://paste.debian.net/989686/
edit2: added comment to wrong issue, removed said comment
Sorry, line 139 also needs to be changed from:
#ifdef _WIN32
to:
#if defined(_WIN32) && !(defined(__MINGW64__) || defined(__MINGW32__))
I already did that. That's where the 989686 log comes in.
Wow I'm not paying attention here. This is actually kind of a major pain. The problem is that Glitch64 has code for defining and assigning function pointers for all these OpenGL functions when it's building under Windows, because Windows doesn't natively support anything after opengl 1.1 (jerks). But your SDL library in mingw64 is also defining the same symbols and presumably handling this issue itself. One possible solution is to undefine some macros to try and trick Glitch64 into thinking that it's building under unix and not windows. You can try building it like this:
make CFLAGS='-U_WIN32 -U__WIN32__'
It's kind of a shot in the dark. We went through a lot of macro hell with all kinds of different platforms back a few years ago. I thought it was mostly sorted out.
That was the fastest it ever attempted to compile... http://paste.debian.net/989725/
OK, I just set up msys2 on a windows machine here and pushed some changes which allow this to build. It requires GLEW now for this environment. Can you please test on your system?
@richard42 Fails to build here with MXE:
/tmp/cce3cFVr.ltrans13.ltrans.o: In function `compile_shader()':
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:404: undefined reference to `__imp___glewUseProgramObjectARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:406: undefined reference to `__imp___glewGetUniformLocationARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:408: undefined reference to `__imp___glewUniform1iARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:413: undefined reference to `__imp___glewUniform4fARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:482: undefined reference to `__imp___glewCreateShaderObjectARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:483: undefined reference to `__imp___glewShaderSourceARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:486: undefined reference to `__imp___glewCompileShaderARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:488: undefined reference to `__imp___glewCreateProgramObjectARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:490: undefined reference to `__imp___glewAttachObjectARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:492: undefined reference to `__imp___glewLinkProgramARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:493: undefined reference to `__imp___glewUseProgramObjectARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:495: undefined reference to `__imp___glewGetObjectParameterivARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:508: undefined reference to `__imp___glewGetUniformLocationARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:510: undefined reference to `__imp___glewUniform1iARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:515: undefined reference to `__imp___glewUniform4fARB'
mupen64plus-video-glide64mk2/projects/unix/../../src/Glitch64/OGLcombiner.cpp:499: undefined reference to `__imp___glewGetInfoLogARB'
Please check https://github.com/mupen64plus/mupen64plus-video-z64/blob/master/projects/unix/Makefile#L193 for the correct way to get+set the glew build flags
Managed to compile for me. Thank you! edit: AAAAAAAAAAAAND it crashes when I start it up. With no record of why it crashed in fact. http://paste.debian.net/990073/
@charlemagnelasse, does the makefile change that I just pushed fix your MXE build?
No, because you forgot this part here: https://github.com/mupen64plus/mupen64plus-video-z64/blob/master/projects/unix/Makefile#L186
Now it will fail because PKG_CONFIG is not defined:
make: Entering directory 'mupen64plus-video-glide64mk2/projects/unix'
/bin/sh: 0: Illegal option --
Makefile:73: *** No GLEW development libraries found!. Stop.
make: Leaving directory 'mupen64plus-video-glide64mk2/projects/unix'
oops, I put the GLEW handling stuff in the wrong place. I just pushed another commit to fix this. Can you test again?
Seems to work here
I have the same issue with video-rice and video-glide64mk2 using Visual Studio and SDL2:
1>------ Build started: Project: mupen64plus-video-rice, Configuration: Release Win32 ------
1>DeviceBuilder.cpp
1>mupen64plus-video-rice\src\OGLExtensions.h(35): error C2365: 'glActiveTexture': redefinition; previous definition was 'function'
1>mupen64plus-win32-deps\SDL2-2.0.6\include\SDL_opengl.h(1878): note: see declaration of 'glActiveTexture'
1>OGLCombiner.cpp
1>mupen64plus-video-rice\src\OGLExtensions.h(35): error C2365: 'glActiveTexture': redefinition; previous definition was 'function'
1>mupen64plus-win32-deps\SDL2-2.0.6\include\SDL_opengl.h(1878): note: see declaration of 'glActiveTexture'
1>OGLExtensions.cpp
1>mupen64plus-video-rice\src\OGLExtensions.h(35): error C2365: 'glActiveTexture': redefinition; previous definition was 'function'
1>mupen64plus-win32-deps\SDL2-2.0.6\include\SDL_opengl.h(1878): note: see declaration of 'glActiveTexture'
1>OGLGraphicsContext.cpp
1>mupen64plus-video-rice\src\OGLExtensions.h(35): error C2365: 'glActiveTexture': redefinition; previous definition was 'function'
1>mupen64plus-win32-deps\SDL2-2.0.6\include\SDL_opengl.h(1878): note: see declaration of 'glActiveTexture'
1>OGLRender.cpp
1>mupen64plus-video-rice\src\OGLExtensions.h(35): error C2365: 'glActiveTexture': redefinition; previous definition was 'function'
1>mupen64plus-win32-deps\SDL2-2.0.6\include\SDL_opengl.h(1878): note: see declaration of 'glActiveTexture'
1>OGLRenderExt.cpp
1>mupen64plus-video-rice\src\OGLExtensions.h(35): error C2365: 'glActiveTexture': redefinition; previous definition was 'function'
1>mupen64plus-win32-deps\SDL2-2.0.6\include\SDL_opengl.h(1878): note: see declaration of 'glActiveTexture'
1>Done building project "mupen64plus-video-rice.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
So it's probably more of a Windows + SDL2 issue, not specific to MinGW
Looks like there is a strong difference between SDL2 and SDL1. See glActiveTexture
declaration of boths here:
SDL1 require GL_GLEXT_PROTOTYPES
to be defined (something we don't define anywhere). With SDL2, SDL_opengl.h seems to define gl functions anyway.
This would mean, if you detect SDL2, add a condition at this line:
https://github.com/mupen64plus/mupen64plus-video-rice/blob/master/src/OGLExtensions.h#L34
Like:
#if defined(WIN32) && !defined(SLD2)
It should work.
@loganmc10 could you try something like this (maybe more hacks are required)? :)
Thanks in advance! :)
I tried commenting those bits out, but then when it goes to link it says that glActiveTexture is an undefined symbol.
Yes, this is the problem. It defines those symbols in the header, but they don't exist in the library.
For the record, glide64mk2 compiles again on my system (it couldn't compile during https://github.com/mupen64plus/mupen64plus-video-glide64mk2/issues/90#issuecomment-335707144 ) but it still crashes in the same place. Any suggestions?
do you know how to run mupen64plus in the debugger and get a stack trace? If not, I could explain; it's not too hard. That's the next step to diagnose your crash.
I know that I might need to recompile some things as debug instead of release, but I don't know where that is necessary, or how to debug a dll instead of an exe
I assume that you are using the build scripts to automatically build off the modules? If so, you can make a debug build by running:
./m64p_build.sh DEBUG=1
Then go into your test directory and start the emulator in the debugger by typing:
gdb --args ./mupen64plus.exe /path/to/testrom.v64
(replace the path with the correct one to the game that you're testing)
Type run
to start the emulator in the debugger. At some point it will crash. Type bt
to get a stack trace and post the results here.
Sorry, couldn't really respond the last few days because the keyboard was broken and took some time to get replaced.
I'm not using the build scripts. I'm cd ing to each module's /projects/unix area and typing "make all"
In that case, go to each module and type make clean
followed by make all DEBUG=1
Once I compile it, how do I debug the specific dll? I mean the rest of the emulator is working properly...
You don't really debug a single DLL; you debug the whole process. I gave instructions in the message above to run it in the debugger "gdb".
So quick recap. Do I have to recompile everything as debug, or just the .exe and the glide64mk2 dll? Because this is the result of me doing that. http://paste.debian.net/992039/
I would recommend rebuilding everything as debug, just to make sure. You also need to type bt
and hit enter after it crashes, to print out the backtrace. From your paste link, it looks like you quit gdb without getting the backtrace.
Looks like something very basic is going wrong here. There's no stack trace, it doesn't even execute a few lines of main(), because it doesn't print out anything before it crashes. I will see if I can reproduce this one my msys windows install.
...any progress?
Sorry, I did look at this a while back and I was able to reproduce the problem. But it doesn't look like anything simple. If I run it with dummy audio and gfx plugins, it runs but of course without any window or sound. If I run it with glide64mk2 and audio-sdl, it opens a window but crashes with no stack trace info for the main thread, and about 13 other threads that are all inside of windows and SDL dlls. That's weird; it doesn't work like that on unix. If I run it with dummy gfx but audio-sdl plugin, it runs without crashing but no window and also no sound (possibly because an open window is necessary for getting audio output). Are there any SDL-based MINGW64 programs that work correctly? Does anybody know how to make the "MXE" builds that Sven was publishing a few years ago? I recall building it once in that environment and it seemed to work fine.
The buildbot still runs (without my supervision) and publishes under https://bitbucket.org/ecsv/mupen64plus-mxe-daily/downloads/?tab=tags . The script to build it can be found in https://bitbucket.org/ecsv/mupen64plus-mxe-daily/src/badbcddc98a5a6b5b01a5e8fcc4b7c946bfd8971/?at=buildenv
I haven't updated the MXE build environment since a while. So you have to do following to get the same build environment as in my builds:
git clone https://github.com/tonytheodore/mxe.git
git -C mxe reset --hard 815d8fe7e18deb2ae50ade063f98cfdd6d155581
git -C am patches/0001-Enable-shared-linking-for-sdl.patch
make -C mxe MXE_TARGETS="i686-w64-mingw32.static x86_64-w64-mingw32.static" gcc sdl2 libpng freetype speex speexdsp libsamplerate pthreads freeglut glew zlib boost JOBS=8
The rest is documented at http://mupen64plus.org/wiki/index.php?title=CrossCompilingOnLinux (or you can use parts of build.sh).
Btw. it looks like glide64mk2 also crashes with my builds since a while. I've just tested it here and bisected it (i686-w64-mingw32.static):
Looks like the glew changes are the problem here. And I've started everything in the cygwin shell via:
chmod +x *; ./mupen64plus.exe --emumode 0 --core ./mupen64plus.dll --input mupen64plus-input-sdl.dll --audio mupen64plus-audio-sdl.dll --rsp mupen64plus-rsp-hle.dll --gfx mupen64plus-video-glide64mk2.dll m64p_test_rom.v64; git reset --hard
Not sure whether this is the problem which you saw.
@Danfun64 @richard42 Please test https://github.com/mupen64plus/mupen64plus-video-glide64mk2/pull/92/commits/60ef39410da2a255132b6ecaaa989911201d5eec (#92). There is also a bug report in https://github.com/mxe/mxe/issues/1961
The rest is documented at http://mupen64plus.org/wiki/index.php?title=CrossCompilingOnLinux (or you can use parts of build.sh).
Those instructions are a little outdated, there's no more stable branch in MXE and shared builds for SDL and SDL2 are enabled so all that's needed is:
git clone https://github.com/mxe/mxe.git
make -C mxe MXE_TARGETS="i686-w64-mingw32.static x86_64-w64-mingw32.static" gcc sdl2 libpng freetype speex speexdsp libsamplerate pthreads freeglut glew zlib boost JOBS=8
i tried 60ef394 , but Mupen64plus doesn't recognize the dll as legitimate.
http://paste.debian.net/994333/ http://paste.debian.net/994334/
@Danfun64 How did you build this before? Because these lines should not change the DLL format (only a single call to glew is added).
@tonytheodore just tested that here and the current master doesn't create the SDL2.dll when doing
git clone https://github.com/mxe/mxe.git
make -C mxe MXE_TARGETS="i686-w64-mingw32.static x86_64-w64-mingw32.static" gcc sdl2 libpng freetype speex speexdsp libsamplerate pthreads freeglut glew zlib boost JOBS=8
So it seems to be correct that the mxe stuff has to be patched to use SDL2 from multiple DLLs (+executables) while having the rest linked as static objects. But your command should work when using *.shared (which also implies that "nothing" is linked statically).
I built it exactly the same way I built it before. After cloning the git repository, I enter projects/unix and "make all".
I think this can be closed.
I'm not quite sure what the issue is. I know either dependencies are missing, or the compiler is looking for the wrong thing. Any suggestions on what I'm doing wrong? http://paste.debian.net/989547/
edit: I have NOT been using mupen64plus-win32-deps, and I can confirm that mupen64plus-core, mupen64plus-rsp-cxd4, mupen64plus-rsp-hle, mupen64plus-ui-console, mupen64plus-input-sdl, and mupen64plus-audio-sdl have successfully compiled with my setup.