libretro: RPI: use new vendor graphics library names

[psyke83]

No description provided.

[joolswills]

Just want to check before merging - the INCFLAGS are not being set now which seems incorrect which was introduced by @gizmo98 's last PR. Is that right @gizmo98 ?

[joolswills]

There have been some reports on the forum that it's not building - I will test.

[psyke83]

Not sure, but I completed a build against this PR a few hours ago and it was successful. Works fine with SDL2.0.6 + RetroArch master on jessie.

[joolswills]

Btw did you see my post regarding sdl 2.0.5 and these changes on RetroPie issue tracker ? If we switch all the packages to the new libraries, will sdl2 apps work with sdl 2.0.5 ?

[joolswills]

Please can you test against current RetroArch and sdl 2.0.5 ? If there are going to be compatibility issues with the various library changes, we will need to make sure we do everything at once, otherwise, I will get a lot of bug reports from users that update certain packages from source.

[joolswills]

(or I will have to implement some workaround like forcing library names).

[psyke83]

I wrote a reply but must have forgot to hit send. The updated packages using the new libraries won't work with SDL 2.0.5 out of the box, no. However, all versions of SDL have the capability to override the driver.

So SDL 2.0.5 would work with new packages with:

SDL_VIDEO_EGL_DRIVER=/opt/vc/lib/libbrcmEGL.so SDL_VIDEO_GL_DRIVER=/opt/vc/lib/libbrcmGLESv2.so

...and SDL 2.0.6 can work with old packages via:

SDL_VIDEO_EGL_DRIVER=/opt/vc/lib/libEGL.so SDL_VIDEO_GL_DRIVER=/opt/vc/lib/libGLESv2.so

[joolswills]

I will have to include that then - or else we are going to have breakage.

[psyke83]

IMO it's probably a good idea to pause your automated builds and wait until all the major stuff has been changed over. SDL 2.0.6 has already switched without our meddling (they just half-assed the patch so it only works on ES2 apps).

[joolswills]

The builds are not automated - they are manually triggered btw - but people build from source all the time and some RPI targets are source only so there will be problems (eg ubuntu).

[joolswills]

I'm already beginning to feel this is being rushed, so we need to put a plan into place to have a smooth migration - especially since patches have been sent upstream etc.

[psyke83]

Hmm.

Everything in core + main has been switched (ES + RetroArch just need bumps/cherrypick)
Optional has many PRs merged. All my PRs for mupen64plus have been merged and it's fully working now. From the list I posted, just 6 or so remaining projects need PRs sent.

We could do a very crude compatibility bodge via runcommand. Scan the binaries in "$md_inst" before running. If it finds libGLES.so, set the environment variables to force the old driver (assuming we put back 2.0.6)...

[joolswills]

mupen64plus is fully working ? With SDL 2.0.6 or ? RetroPie is on 2.0.5 btw currently not 2.0.6 - it was reverted.

[psyke83]

Yes, I reverted your revert so I can test my PRs against 2.0.6. mupen64plus definitely works ok with all plugins. I'm testing on jessie with SDL 2.0.6, ES master & RetroArch master.

[joolswills]

I will have a think about runcommand. I hadn't realised about these compatibility issues, and it would have been better to plan ahead better - which is also my fault for not testing better. We could for example introduce a flag for some packages, which might be better than trying to scan binaries.

[joolswills]

so when you say mupen64plus is fully working - in my mind it isn't. it's broken - it's fully working on sdl 2.0.6 which we are not yet using. So no doubt there will be more people reporting issues.

No real nice fix for this either now since we have some stuff changed and some not. what a mess :(

[joolswills]

What other SDL2 packages have been changed apart from mupen64plus ? (Can use the main issue tracker on Retropie-Setup for this).

[psyke83]

Something like this is what I mean (replace the path with the appropriate variable.. $md_inst?):
[[ $(grep -r libGLESv2.so /opt/retropie/ports/quake3/) ]] && needs_env_var

This will not trigger if the folder doesn't return a match.

[joolswills]

Yes, I understood scanning the binaries etc, which could be slow (for those that contain many files). Hence thinking a manual flag might be better.

[psyke83]

I installed all optional packages to identify the necessary changes. Here's the current list I'm working from.

pi@retropie:~/RetroPie-Setup $ cat GLESs.log
Binary file /opt/retropie/emulators/atari800/bin/atari800 matches ARCHIVE
Binary file /opt/retropie/emulators/coolcv/coolcv_pi matches ARCHIVE
Binary file /opt/retropie/emulators/gpsp/gpsp matches  https://github.com/libretro/gpsp.git
Binary file /opt/retropie/emulators/pcsx-rearmed/pcsx matches https://github.com/libretro/pcsx_rearmed.git
Binary file /opt/retropie/emulators/pcsx-rearmed/plugins/gpu_gles.so matches https://github.com/libretro/pcsx_rearmed.git
PR Binary file /opt/retropie/emulators/pisnes/snes9x.gui matches https://github.com/RetroPie/pisnes.git
PR Binary file /opt/retropie/emulators/pisnes/snes9x matches
Binary file /opt/retropie/emulators/ppsspp/PPSSPPSDL matches https://github.com/hrydgard/ppsspp.git
Binary file /opt/retropie/emulators/reicast/bin/reicast matches  https://github.com/RetroPie/reicast-emulator.git retropie
Binary file /opt/retropie/emulators/rpix86/rpix86 matches ARCHIVE
Binary file /opt/retropie/libretrocores/lr-mupen64plus/mupen64plus_libretro.so matches TEST
PR Binary file /opt/retropie/libretrocores/lr-parallel-n64/parallel_n64_libretro.so matches TEST https://github.com/libretro/parallel-n64.git
PR Binary file /opt/retropie/libretrocores/lr-ppsspp/ppsspp_libretro.so matches TEST https://github.com/RetroPie/ppsspp.git libretro_rpi_fix
Binary file /opt/retropie/ports/cannonball/cannonball matches
Binary file /opt/retropie/ports/darkplaces-quake/darkplaces-sdl matches
Binary file /opt/retropie/ports/dxx-rebirth/d1x-rebirth matches
Binary file /opt/retropie/ports/dxx-rebirth/d2x-rebirth matches
Binary file /opt/retropie/ports/giana/giana_rpi matches
Binary file /opt/retropie/ports/quake3/ioq3ded.arm matches
Binary file /opt/retropie/ports/quake3/ioquake3.arm matches

I'm testing my patches before submitting. The ones prefixed with PR have active PRs waiting to be merged. Not many are left.

I'm leaving the programs with tarballs until last. Will you accept patches to RetroPie-Setup to add sed regex replacements for these? (I can queue them all together so that everything is fixed together).

[joolswills]

the packages above have been switch to the new library names or still use the old library names ? I would like a list of ones which have been switched to the new library names (and use SDL2)

I will accept patches, but I don't feel we have a plan of attack yet, and would like to agree on way forward first.

[joolswills]

The other thing is I don't have much free time this weekend.

[psyke83]

Everything on the above list uses SDL except for the libretro cores, so they need changes for the new vendor library names & SDL 2.0.6 (without environment variables set).

My active PRs:
#2
libretro/parallel-n64#469

I'm not sure what to do except continue sending PRs for the remaining items on that list. Whatever remains on the old libraries or is closed source can use some kind of runcommand flag (set manually to avoid slowdown, as you said).

I can probably have PRs sent for everything in the "optional" repo by tonight. It's been going slow as I've been making sure to compile and run test. But the PRs have been getting merged quickly.

[joolswills]

I was thinking to do it the other way around - set a flag for things that have been done. Unfortunately the more PRs you get accepted today, the more packages that will be broken right now. Hence my comment about this being badly planned and rushed - and I dont have the free time right now.

[psyke83]

OK, I'll stop sending PRs, make a list of the updated programs and work on a way to set the flags for them. But keep in mind that not all applications break with SDL 2.0.6 vs the old libraries. For example, ioquake3 as-is (linked to libGLESv2) works fine with SDL 2.0.6.

[joolswills]

Thanks. My first thought would be a function that touches a file in md_inst, but can go with a solution that extracts the libs from the executable if we can do it without grepping the whole dir. Eg testing the actual binary to be launched (or the libretro .so etc).

Can also use a cmd to extract lib names rather than grep.

[joolswills]

Wouldn't work for emus that use launch scripts though so the flag would be more reliable imho.

[psyke83]

One glaring issue is retroarch due to the dynamic libraries. RetroArch links to the GLES library, but so do some cores. If there's a mismatch, it won't be possible to fix that with flags.

What I can do is set up a temporary branch for all the libretro cores that have already changed. We can point to my repos temporarily in RetroPie-Setup (temporarily) so that upstream doesn't need to be disturbed. What do you think? I can send a PR to change all the affected repos at once, which can be reverted later.

For the standalone applications, flags will probably work, so I'll still work on that idea.

[joolswills]

I don't have time to do this this weekend - so we will have to stick with a few broken packages (if installed via source), until I have time - I don't even have time to review. I was hoping to have a break this weekend from retropie (even this topic is taking up time I don't have).

[psyke83]

I'll try to work on minimizing the issues which should hopefully be ready for you to merge on Monday. Apologies for taking up your time -- now take your break! ;)

I'll write a post on the forum recommending for people not to update (especially from source) for a while.

[joolswills]

Thanks. :)

[gizmo98]

@joolswills
GLES2 and EGL headers can be found under /usr/include so we do not need extra INCFLAGS if MESA drivers are used.

[joolswills]

@gizmo98 my bad - i misread the confusing Makefile logic :-) I read it as the INCDIR being set for when the flag mesa is set, rather than when not mesa.

[psyke83]

@joolswills

Here's my proposed solution: RetroPie/RetroPie-Setup@master...psyke83:vendor_workaround

I'm still testing to make sure it works 100% as intended :). The grep is not very slow even on a large project like mupen64plus (probably since it executes immediately after checkout, hence the files are cached in memory).