stefan-gr / abendbrot

Desktop oriented overlay for various ebuilds and the occasional gamer
19 stars 13 forks source link

mupen64plus-libretro is not the same #52

Closed ghost closed 7 years ago

ghost commented 7 years ago

Hello,

When I dowload it from retroarch it runs well. But from the overlay it's says : RetroArch [ERROR] :: Requesting OpenGLES2 context, but RetroArch is compiled against OpenGL. Cannot use HW context.

That's strange, because I just finish a fresh install but before that I didn't have this problem.

PS: gles2 is a global useflag for me.

stefan-gr commented 7 years ago

Hi,

Could you post your active USE flags for mupen64plus-libretro and retroarch? That should only happen when gles2 is enabled in a core but not in retroarch itself. Also, did you try using gles3 for retroarch?

If you aren't using retroarch on arm or in kms mode then you should consider using plain opengl without gles2/3 since that is what the cores from upstream use as well, that's why they work.

ghost commented 7 years ago

gles2 was set because it's a global use flags.

[ebuild  N    ] games-emulation/libretro-info-1.0_pre20161130 
[ebuild  N    ] games-emulation/common-overlays-1.0_pre20161108 
[ebuild  N    ] games-emulation/slang-shaders-1.0_pre20160918 
[ebuild  N    ] games-emulation/retroarch-assets-1.0_pre20161031 
[ebuild  N    ] games-emulation/libretro-database-1.0_pre20161125 
[ebuild  N    ] media-libs/vulkan-loader-1.0.30.0 
[ebuild  N    ] games-emulation/scummvm-libretro-1.0_pre20161125  USE="-debug" 
[ebuild  N    ] games-emulation/mupen64plus-libretro-1.0_pre20161101  USE="gles2 -debug" 
[ebuild  N    ] games-emulation/stella-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/mednafen-ngp-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/bsnes-libretro-1.0_pre20161104  USE="profile_balanced -profile_accuracy -profile_performance" 
[ebuild  N    ] games-emulation/prboom-libretro-1.0_pre20161106  USE="-debug" 
[ebuild  N    ] games-emulation/mednafen-supergrafx-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/desmume-libretro-1.0_pre20161101  USE="-debug" 
[ebuild  N    ] games-emulation/handy-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/mednafen-pce-fast-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/genplus-libretro-1.0_pre20161108  USE="-debug" 
[ebuild  N    ] games-emulation/mednafen-gba-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/mednafen-wswan-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/prosystem-libretro-1.0_pre20161025  USE="-debug" 
[ebuild  N    ] games-emulation/pcsx-rearmed-libretro-1.0_pre20161126  USE="-debug (-neon)" 
[ebuild  N    ] games-emulation/4do-libretro-1.0_pre20161009  USE="-debug" 
[ebuild  N    ] games-emulation/beetle-psx-libretro-1.0_pre20161212  USE="vulkan -debug -opengl" 
[ebuild  N    ] games-emulation/reicast-libretro-1.0_pre20161119  USE="gles2 -debug -naomi" 
[ebuild  N    ] games-emulation/mednafen-vb-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/nxengine-libretro-1.0_pre20161107  USE="-debug" 
[ebuild  N    ] games-emulation/psp-assets-1.2.1-r1 
[ebuild  N    ] dev-libs/libzip-1.1.3  USE="-static-libs" 
[ebuild  N    ] games-emulation/retroarch-joypad-autoconfig-1.0_pre20161126 
[ebuild  N    ] games-emulation/psp1-libretro-1.0_pre20160803  USE="gles2 -debug" 
[ebuild  N    ] games-emulation/mgba-libretro-1.0_pre20161122  USE="ffmpeg gles2 opengl png zip zlib -epoxy -imagemagick -lto -lzma -pgo -pgopost" 
[ebuild  N    ] games-util/joystick-1.6.0  USE="udev -sdl" 
[ebuild  N    ] games-emulation/libretro-meta-1-r1  USE="4do beetle-psx bsnes desmume genplus handy mednafen-gba mednafen-ngp mednafen-pce-fast mednafen-supergrafx mednafen-vb mednafen-wswan mgba mupen64plus nxengine pcsx-rearmed prboom prosystem psp1 reicast scummvm stella -2048 -bnes -craft -dolphin -fbalpha -fbalpha2012 -fceumm -gambatte -mame -mame2000 -mednafen-snes -meteor -nestopia -parallel -picodrive -ppsspp -quicknes -snes9x -snes9x2002 -snes9x2010 -tgbdual -tyrquake -vba-next -vbam -yabause" 
[ebuild  N    ] games-emulation/retroarch-9999-r3  USE="7zip X alsa assets cores database egl fbo ffmpeg gles2 gles3 jack joypad_autoconfig materialui netplay network opengl overlays pulseaudio shaders threads truetype udev vulkan xmb xml zlib (-armvfp) -cg -cheevos -debug -dispmanx -kms -libass -libusb -miniupnpc (-neon) -openal -osmesa -oss -python -sdl -sdl2 -v4l2 -videocore -wayland -xinerama -xv" CPU_FLAGS_X86="sse2" PYTHON_SINGLE_TARGET="-python3_4 -python3_5" PYTHON_TARGETS="python3_4 -python3_5" 

I wanted to try a clean rebuild (because I upgraded to gcc-6.2) and remove wayland by the same way. But this time I have a error more crazy : retroarch: error while loading shared libraries: libwayland-egl.so.1: cannot open shared object file: No such file or directory

I removed wayland, egl, gles2 and gles3, but still the same message. [ebuild R ] games-emulation/retroarch-9999-r3 USE="7zip X alsa assets cores database fbo ffmpeg jack joypad_autoconfig materialui netplay network opengl overlays pulseaudio shaders threads truetype udev vulkan xmb xml zlib (-armvfp) -cg -cheevos -debug -dispmanx -egl -gles2 -gles3 -kms -libass -libusb -miniupnpc (-neon) -openal -osmesa -oss -python -sdl -sdl2 -v4l2 -videocore -wayland -xinerama -xv" CPU_FLAGS_X86="sse2" PYTHON_SINGLE_TARGET="-python3_4 -python3_5" PYTHON_TARGETS="python3_4 -python3_5"

I'm going to try kms, seems more easy.

EDIT: With kms and egl, same error.

stefan-gr commented 7 years ago

I'm on gcc-5.4 and I can reproduce it with games-emulation/retroarch sdl2 -wayland but only when media-libs/libsdl2 is build with wayland. It seems to be an indirect dependency caused by the sdl2 flag. It works properly when media-libs/libsdl2 is build with -wayland before rebuilding retroarch with -wayland.

I tested the same flags you have and the resulting binary does not link to wayland or sdl for me, so gcc-6.2.0 seems to misbehave or the error message is slightly different. Could you post the current exact error message, retroarch use flags and emerge --info?

ghost commented 7 years ago

Same error with sdl2 (libsdl2 wasn't installed). But the error it's not a compile error, it's something I got when I try to run retroarch (just to be clear).

http://pastebin.com/zGjMA1nK

Well I'm going to try with gcc 5.4 who know

EDIT: Same thing with gcc 5.4, or maybe I need to rebuild everything.

stefan-gr commented 7 years ago

ldd /usr/bin/retroarch helps detecting directly missing libraries. But it is probably easier to just run revdep-rebuild -i from app-portage/gentoolkit. Normally, portage preserves needed libraries and reminds you of them every time emerge is run. Did you remove something with emerge --unmerge? Well, it still should make sure that used libraries aren't removed. I don't know what could cause this since you have preserve-libs in FEATURES.

ghost commented 7 years ago

Just for a try I get back the full egl gles gles2 gles3 wayland, and launch retroarch, same error with mupen64plus. Should I use a specific driver? sdl2 with gles2 maybe? I'm going to remove wayland and others to check ldd.

stefan-gr commented 7 years ago

Did you mean RetroArch [ERROR] :: Requesting OpenGLES2 context, but RetroArch is compiled against OpenGL. Cannot use HW context.? That should only happen when you have gles2 on it but not in retroarch. Do you perhaps load an old one from the retroarch updater or do you use a local retroarch without noticing it? Try it with a clean retroarch config and don't use retroarch's history since it saves the used core path too.

ghost commented 7 years ago

So I got 2 runtime errors :

[ebuild   R   ] games-emulation/mupen64plus-libretro-1.0_pre20161101  USE="-debug -gles2*" 
[ebuild   R   ] games-emulation/retroarch-9999-r3  USE="7zip X alsa assets cores database fbo ffmpeg jack joypad_autoconfig materialui netplay network opengl overlays pulseaudio shaders threads truetype udev vulkan xmb xml zlib (-armvfp) -cg -cheevos -debug -dispmanx -egl* -gles2* -gles3* -kms* -libass -libusb -miniupnpc (-neon) -openal -osmesa -oss -python -sdl -sdl2 -v4l2 -videocore -wayland -xinerama -xv" CPU_FLAGS_X86="sse2" PYTHON_SINGLE_TARGET="-python3_4 -python3_5" PYTHON_TARGETS="python3_4 -python3_5" 
RetroArch [ERROR] :: Requesting OpenGLES2 context, but RetroArch is compiled against OpenGL. Cannot use HW context.
RetroArch [libretro ERROR] :: mupen64plus: libretro frontend doesn't have OpenGL support.RetroArch [ERROR] :: Failed to load content.
[ebuild   R   ] games-emulation/mupen64plus-libretro-1.0_pre20161101  USE="gles2* -debug" 
[ebuild   R   ] games-emulation/retroarch-9999-r3  USE="7zip X alsa assets cores database egl* fbo ffmpeg gles2* gles3* jack joypad_autoconfig kms* materialui netplay network opengl overlays pulseaudio shaders threads truetype udev vulkan wayland* xmb xml zlib (-armvfp) -cg -cheevos -debug -dispmanx -libass -libusb -miniupnpc (-neon) -openal -osmesa -oss -python -sdl -sdl2 -v4l2 -videocore -xinerama -xv" CPU_FLAGS_X86="sse2" PYTHON_SINGLE_TARGET="-python3_4 -python3_5" PYTHON_TARGETS="python3_4 -python3_5" 

So if I'm not wrong, the only way to use mupen64plus for me now, is to use wayland useflag (well that's not a problem, but not really sure that retroarch can launch a wayland instance by itself), and download the mupen64plus core.

stefan-gr commented 7 years ago

That looks like your system is in an inconsistent state.

When I compile without wayland useflag (even without egl, gles2 and gles3) , I got : retroarch: error while loading shared libraries: libwayland-egl.so.1: cannot open shared object file: No such file or directory

Did you make sure to run without errors emerge -avuDN world and emerge --depclean after each flag change you did? Missing library errors can't happen without outside influence because emerge WILL fail if it can't find the libraries it wants when linking the final binary. This means that retroarch was build with sdl2/wayland and something later just removed the libraries outside of depclean and it will generate this runtime error.

I even tried to just delete /usr/lib64/libwayland-* and see what happens with retroarch wayland and -wayland. It throws the same error as you and as soon as it gets reemerged it fails because that library is obviously missing. revdep-rebuild fixed that for me. Setting -waylandglobally made also sure that retroarch doesn't link to it directly or indirectly.

I'm not sure how I can help with this without ssh access or something else. I would just bite the bullet, if I were you, and set wayland globally to be done with it.

So if I'm not wrong, the only way to use mupen64plus for me now, is to use wayland useflag (well that's not a problem, but not really sure that retroarch can launch a wayland instance by itself), and download the mupen64plus core.

Wayland will only be used when retroarch is started in a wayland session. Though, it fails for me because of some llvm error. Nice.

Did you try cleaning your retroarch-core.cfg? You could also try disabling vulkan to see if that changes anything, it takes a while to compile and has special shaders compiled in, that flag needs some work from me when I buy my next gpu.

ghost commented 7 years ago

Well I give up, I even did a full rebuild with gcc 5.4, same errors. Wayland was a global useflag, like vulkan. And without vulkan I got the same errors to. So I really don't know what's going on. I did emerge --depclean, revdep-build... I was thinking a issue, because it's the first time I got a problem with your ebuild. I always use it on wayland thought. But in the end that's not a real problem for me (I play so little for begin with). But maybe it's just my system, even if I just did an emerge -avq @world to install my system (all my software are in text files). Anyway thanks for your time, but I need to focus on my work ^^

stefan-gr commented 7 years ago

When you have the time please provide the build logs for all libretro related ebuilds and try everything with a clean user, perhaps some config files are in the way.

Anyway thanks for your time, but I need to focus on my work ^^

Oh well, at least you can use the upstream provided builds. Please reopen it when you want to tackle it again.