mupen64plus / mupen64plus-video-glide64mk2

Video plugin for Mupen64Plus 2.0 based on 10th anniversary release code from gonetz
28 stars 37 forks source link

Unable to compile on MSYS2 #90

Closed Danfun64 closed 2 years ago

Danfun64 commented 6 years ago

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.

richard42 commented 6 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__)

Danfun64 commented 6 years ago

I made the change to that file, but I get almost the same result. http://paste.debian.net/989659/

richard42 commented 6 years ago

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?

Danfun64 commented 6 years ago

http://paste.debian.net/989669/

richard42 commented 6 years ago

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.

Danfun64 commented 6 years ago

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

richard42 commented 6 years ago

Sorry, line 139 also needs to be changed from: #ifdef _WIN32 to: #if defined(_WIN32) && !(defined(__MINGW64__) || defined(__MINGW32__))

Danfun64 commented 6 years ago

I already did that. That's where the 989686 log comes in.

richard42 commented 6 years ago

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.

Danfun64 commented 6 years ago

That was the fastest it ever attempted to compile... http://paste.debian.net/989725/

richard42 commented 6 years ago

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?

ghost commented 6 years ago

@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

Danfun64 commented 6 years ago

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/

richard42 commented 6 years ago

@charlemagnelasse, does the makefile change that I just pushed fix your MXE build?

ghost commented 6 years ago

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'
richard42 commented 6 years ago

oops, I put the GLEW handling stuff in the wrong place. I just pushed another commit to fix this. Can you test again?

ghost commented 6 years ago

Seems to work here

loganmc10 commented 6 years ago

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

Narann commented 6 years ago

Looks like there is a strong difference between SDL2 and SDL1. See glActiveTexture declaration of boths here:

https://github.com/mupen64plus/mupen64plus-win32-deps/blob/master/SDL-1.2.15/include/SDL_opengl.h#L3235

https://github.com/mupen64plus/mupen64plus-win32-deps/blob/master/SDL2-2.0.6/include/SDL_opengl.h#L1878

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! :)

loganmc10 commented 6 years ago

I tried commenting those bits out, but then when it goes to link it says that glActiveTexture is an undefined symbol.

richard42 commented 6 years ago

Yes, this is the problem. It defines those symbols in the header, but they don't exist in the library.

Danfun64 commented 6 years ago

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?

richard42 commented 6 years ago

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.

Danfun64 commented 6 years ago

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

richard42 commented 6 years ago

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.

Danfun64 commented 6 years ago

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"

richard42 commented 6 years ago

In that case, go to each module and type make clean followed by make all DEBUG=1

Danfun64 commented 6 years ago

Once I compile it, how do I debug the specific dll? I mean the rest of the emulator is working properly...

richard42 commented 6 years ago

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".

Danfun64 commented 6 years ago

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/

richard42 commented 6 years ago

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.

Danfun64 commented 6 years ago

Umm... http://paste.debian.net/992179/

richard42 commented 6 years ago

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.

Danfun64 commented 6 years ago

...any progress?

richard42 commented 6 years ago

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.

ecsv commented 6 years ago

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).

ecsv commented 6 years ago

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.

ghost commented 6 years ago

@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

tonytheodore commented 6 years ago

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
Danfun64 commented 6 years ago

i tried 60ef394 , but Mupen64plus doesn't recognize the dll as legitimate.

http://paste.debian.net/994333/ http://paste.debian.net/994334/

ghost commented 6 years ago

@Danfun64 How did you build this before? Because these lines should not change the DLL format (only a single call to glew is added).

ghost commented 6 years ago

@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).

Danfun64 commented 6 years ago

I built it exactly the same way I built it before. After cloning the git repository, I enter projects/unix and "make all".

Jj0YzL5nvJ commented 2 years ago

I think this can be closed.