Add Raspbian Stretch support
Closed this issue · 74 comments
Notes for myself:
- Test gcc 6 compatibility
- rework SDL2 / ES and other GLES apps for new GLES library locations
- Rebuild all binaries for stretch
- Test new image based on stretch.
- Build retroarch against ffmpeg.
Good luck! I upgraded an image to stretch a day or so ago and had a lot of trouble getting emulationstation to compile properly (linker errors related to GL functions). Comparing the CMakeCache.txt, it seems that on stretch it wasn't using libraries and includes from /opt/vc related to GLES (files like /opt/vc/lib/libGLESv2_CM.so and its v1 symlink went missing after the upgrade).
I got it compiled eventually after installing various GLEW packages that weren't installed/necessary on jessie, but it still failed to launch with an SDL library initialization error.
yeah they no longer include non broadcom libs in libraspberrypi-dev so the ES cmake search paths need changing etc. the SDL2 library probably also needs changes. I will have to rework a bunch of stuff I guess.
This will be fun. Without dispmanx support we can remove gpsp and all rpi... emulators and enable display output resolution switiching for rpi1/zero again.
I tried to compile SDL2 with kms video backend so we do not need X11. It's a relatively new SDL2 feature. Commit is 17 days old. SDL2 compiles fine but EmulationStation fails at startup.
https://github.com/RetroPie/RetroPie-Setup/compare/master...gizmo98:rpi-kms?expand=1
https://github.com/spurious/SDL-mirror/compare/master...gizmo98:retropie-kms-2.0.5?expand=1
SDL2 kms docu:
spurious/SDL-mirror@9afeb8f
https://github.com/sigmaris/SDL-mirror/commits/kmsdrm
https://forums.libsdl.org/viewtopic.php?p=51389
retroarch kms docu:
https://github.com/libretro/RetroArch/wiki/KMS-mode
I have not modified EmulationStation. Changing or removing broadcom paths could help.
I downloaded raspbian stretch today. /opt/vc libs is there and the old driver seems to be enabled by default.
Ok. Emulationstation runs now from console. I can build Retroarch with kms support if i rename /opt/vc. PRBoom runs fine.
@gizmo98 did you use the lite version or the desktop version
Desktop version.
I think there must be a bit of confusion - the libraries are definitely missing on stretch. I downloaded a lite image to check and it's the same as a dist-upgrade from jessie. The needed libraries are not part of libraspberrypi0 or libraspberrypi-dev.
@joolswills
I think that libgles2-mesa and libgles2-mesa-dev needs to be added as an ES dependency. I'm fairly sure that on jessie, /opt/vc/lib/libGLESv1_CM.so was already a symlink to libGLESv2.so, so you can either recreate the symlink in /usr/lib/arm-linux-gnueabihf or (probably better), edit the ES's FindOpenGLES.cmake so that it also searches for the v2 library directly:
NAMES GLES_CM GLESv1_CM GLESv2
OR, if the libgles2-mesa libraries aren't compatible, this may be the solution?
NAMES GLES_CM GLESv1_CM GLESv2_static
That will use /opt/vc/lib/libGLESv2_static.a which is still part of libraspberrypi-dev.
@psyke83
Don't know. I downloaded a desktop image today. raspi-config still allows to select a GL driver under advanced. I had to enable the FULL KMS driver manually.
OK, more info:
The libraries have been deliberately removed due to conflicts with the original libs: anholt/mesa#24 (comment)
The solution is to use the new names:
/opt/vc/lib/libbrcmEGL.so /opt/vc/lib/libbrcmGLESv2.so /opt/vc/lib/libbrcmOpenVG.so /opt/vc/lib/libbrcmWFC.so
EmulationStation:
- CMakeLists.txt: change EGL to brcmEGL for BCMHOST case
- OpenGLES.cmake: change GLESv1_CM to brcmGLESv2 (v1 is already a symlink to v2 on jessie)
- If ES explicitly requests the v1 library, then it needs to be changed to v2, or the v1 - v2 symlink needs re-creating (see SDL below)
SDL:
- Modify hardcoded library names to the new names: https://github.com/RetroPie/SDL-mirror/blob/retropie-2.0.5/src/video/SDL_egl.c#L43
Not sure if that's enough to restore ES to working order, I'm still compiling...
Run raspi-config and select the old GL driver there. This should solve the problem.
The old driver is active by default. No, I can confirm the above information was correct including my hunch that ES needed to be changed to request the major version 2. I'm just doing one more rebuild to be sure before sending the PRs.
These two PRs fix ES + SDL on stretch, and should still work on jessie:
RetroPie/EmulationStation#216
RetroPie/SDL-mirror#7
Will continue building the rest of the core packages. Anything that links to libEGL or libGLES* will need to be changed to link to the libbrcm versions. Otherwise, the SDL PR will presumably fix anything else that doesn't link the wrong libraries.
Update 1:
RetroArch PR:
libretro/RetroArch#5350
Upstream PR for RetroArch submitted - the expected issue of not linking the correct libraries. RetroArch builds with my PR, and so far I've compiled lr-tyrquake core to confirm it's working. However, the image was not stretching to the screen, but if I enable fullscreen mode in retroarch's display settings, the game's display shows as expected.
@psyke83
I see. There are even more packages which need updates. GPSP, lr-mupen64plus, lr-ppsspp, reicast, mupen64plus, ppsspp and so on.
SDL2 updates should be posted upstream as well.
Yes. RetroArch builds correctly but it seems not to running correctly (it starts up, but many cores segfault). My PR was merged, but it's still linking the standard EGL/GLES libraries in addition to the brcm version, which I'm guessing is causing problems. Will check into this.
Update 2: RetroArch builds, but still links the wrong libraries. Unfortunately, the brcm libs don't come packaged with the pkgconfig files in order to facilitate linking.
libretro/RetroArch#5351
With the above patch & workaround, I've tested:
lr-picodrive: segfaults
lr-genesis-plus-dx: works
lr-fceumm: works
lr-tyrquake: works
Update 3: The RetroArch PR was (prematurely?) merged. In order to prevent both jessie and stretch breaking from this change, the necessary pkg-config files need to be installed. I raised an issue here: raspberrypi/firmware#857
Temporary fix in the meantime (not ideal - they should be packaged with the firmware):
Manually copy https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc/lib/pkgconfig/brcm* to /opt/vc/lib/pkgconfig, and set PKG_CONFIG_PATH to /opt/vc/lib/pkgconfig somewhere in RetroPie-Setup so that it is present during ./configure.
I appreciate all the research done here by both of you, but please can you stop submitting Stretch related PRs. This ticket is assigned to me which means I am working on it - we are duplicating efforts. Also, there is no rush for this, and I am not going to include any library changes until after the next retropie image. PRs with one liner library changes are really not any help.
If you have an idea for a change, please discuss here first, so you can make sure it's not overlapping with anything I am doing.
I've closed the existing PRs to reduce confusion. Apologies! The upstream PR to RetroArch (update 3 I mentioned above) was merged and this will unfortunately will break building on jessie until the pkgconfig issue is fixed in the firmware packages. Apologies for that (but in my defense, I did ask for them not to merge yet).
You mentioned Kodi in the other PR - I thought that the issue was that certain dependent packages weren't built yet, not to do with the library names.
The PRs that I did send to RetroPie-related repos would only break firmwares older than 1.20160921-1, which definitely includes RetroPie 4.0. I'm not sure if 4.1 was transitioned to jessie, as I first tested on build 4.2. As I said, I'll cease with the PRs to avoid duplication of effort. :)
No need to apologise. Your contributions to the project are appreciated.
regarding Kodi - a user had a problem with the link libraries not being found - fixed by updating the system packages, so I assume they had a related problem.
My first step I think will be to make sure the libraspberrypi package is up to date - I can force that in retropie-setup. Am currently trying to get things ready (and stable enough) for a new image release, and after that, we can look into making things Stretch compatible.
I also need to redo the retropie sdl fork/branches so we have a single branch to maintain rather than multiple branches for mali / x / raspberry pi etc. then we can apply any fixes to the sdl for the new libraries etc.
A shame the retroarch PR got accepted before it was ready. Either it will have to be reverted (upstream raspberry pi userland changes will take a while to filter down to Jessie), or we will need to include a patch to revert it as part of retropie-setup or else we will be stuck on the current version.
Yes, that commit was premature, but eventually this issue will need to be sorted properly, even for jessie. There's an alternate way to ensure compatibility with both jessie and stretch (even before libraspberrypi-dev includes the necessary pkgconfig on the latter distribution).
Take a look at this script. https://gist.github.com/psyke83/7070b090e12d3022aa405b964a2f8170
I know, I know, it's overkill! ;) However, you can easily adapt it to generate archives for all the tagged firmware releases after 1.20160921-1, and then use a simplified method to fetch matched archives from your retropie server and export the right PKG_CONFIG_PATH variable.
There will still be some small complications with passing environment variables from retropie-setup's bash scripts to a dash subshell. For example, it doesn't get passed to RetroArch's "./configure" due to it using "/bin/sh". Changing to "bash ./configure" fixes the issue, however. Not a big deal.
If we have the pkgconfig available (making sure that the egl, glesv2, and vg configurations point to the new library names), then RetroArch will build properly without needing that premature commit.
Edit: don't worry about the premature commit - it's reverted now. I'll hold off on doing any further damage, haha.
I started to play around with kms support before stretch was released 😉.
Just a short status report.
SDL2, EmulationStation, Retroarch and Mupen64Plus run. RetroArch shaders do not load. According to retroarch log one GLES OES extension is missing. Mupen64Plus runs even slower. Some games run better (Conker BFD).
I've been thinking that it might be a good idea to include a copy of the firmware libs' pkgconfig in RetroPie-Setup. The next stretch firmware will include it in "/opt/vc/lib/pkgconfig", but there's no guarantee that this change will be backported to jessie (or if jessie will receive any firmware updates at all).
Would you be amenable to adding a version of this change? psyke83@b17fb8d1c2446c8522f1a0c
I would update the patch to fix the code style that you prefer (such as double brackets), but also to add something like this to the last part:
[[ ! -d /opt/vc/lib/pkgconfig ]] && export PKG_CONFIG_PATH="$scriptdir/pkgconfig"
We can then add a copy of the pkgconfig files to RetroPie-Setup, which can be considered a fallback (that we can later remove if jessie's firmware is updated). This will allow us to start working on submitting upstream patches to switch to the new library names, but we can send cleaner patches that avails of the proper pkgconfig detection rather than hacks, and we can be sure that both jessie and stretch will work.
The VC4 driver is not ready to be the primary driver, but it may be a good idea to lay the groundwork by adding the kms/dispmanx flags. IMO, we should send PRs that simultaneously fix the library name and include a bypass for the existing ugly hacks that unconditionally build against the vendor driver, even though we're not focused on making VC4 the default any time soon.
I'm happy to accept that.
(the PKG_CONFIG_PATH change) - I don't want to accept any change to allow people to use retropie-setup with the VC4 driver yet - some enable by accident, and I would prefer to just tell them they need to switch it off for now (which it does via retropie-setup I think).
Agree that VC4 shouldn't be user-selectable yet. What about this? master...psyke83:rpi-fkms
I split into two patches:
- The first will set the graphics flags, but it will also hard block script execution if f/kms is detected; it will show the same dialog warning about the driver being unsupported, but the script will then exit.
- The second includes the fallback pkgconfig (separate commit so it can be cleanly reverted in future, if necessary).
If you're still not happy with the flags being included, I can just submit a version of the second commit that deals with pkgconfig alone... but let me know if it's ok for me to put it in same place and if the function name (get_rpi_video) is ok. Thanks.
I would be interested in looking into a way to check for which driver is loaded, rather than looking for the config.txt - maybe via running modules, or some kernel variable.
I believe that's possible via the sys node via running modules, yes. I'll check that in a few hours (and will also update the splash PR too).
thanks.
Update, since the pkgconfig is in place:
RetroArch works on stretch (vendor and mesa). It will now correctly use pkgconfig if available, but the non-pkgconfig fallback will also check for the new library names: libretro/RetroArch@b67e6dc
I submitted a patch to fix EmulationStation (master branch). It doesn't use pkgconfig, but instead cleans up the manual detection to avoid conflicts between the mesa and vendor headers:
RetroPie/EmulationStation#254
SDL2 can be built with dual support for KMSDRM and RPI drivers. I've been testing it on stretch with EmulationStation and RetroArch; the vendor and mesa driver works fine with the same SDL2 library.
I'll send the PR if you want (I'm not sure if you intend to re-do the branch first): RetroPie/SDL-mirror@rpi-2.0.6...psyke83:rpi-kms
I'll stop spamming big changes, but I hope you don't mind if I continue sending PRs for the small bugs.
please do.
I see. Both of you caused the current mupen64plus problems. ;-)
41633b9
Is this the right time now to post PRs with library names brcmEGL / brcmGLESv2?
I've got mupen64plus working on stretch with all plugins except GLideN64. I still need more time to fix that, and then make sure it's still working on jessie.
As for the reports on jessie, if the problem was due to mupen64plus using an ES1/PVR context, that should already be fixed by my changes that @joolswills merged yesterday (or this morning?). I'll check jessie soon.
Are you testing the latest SDL2 package with my patches?
I build the latest sdl2 and mupen64plus package two hours ago.
OS: raspbian jessie
On jessie, libgbm-dev isn't installed by default, which disables the kmsdrm driver. Make sure libgbm-dev (and libdrm-dev) is installed, and try to rebuild SDL2.
I'm currently testing now but will need some time.
OK, yes, it's a bad interaction between the new and old libraries (which aren't identical) caused by SDL.
This fixes it (not suggesting to use my repos by default, will send PRs):
diff --git a/scriptmodules/emulators/mupen64plus.sh b/scriptmodules/emulators/mupen64plus.sh
index 6f21093..7af7635 100644
--- a/scriptmodules/emulators/mupen64plus.sh
+++ b/scriptmodules/emulators/mupen64plus.sh
@@ -25,7 +25,7 @@ function depends_mupen64plus() {
function sources_mupen64plus() {
local repos=(
- 'mupen64plus core'
+ 'psyke83 core'
'mupen64plus ui-console'
'mupen64plus audio-sdl'
'mupen64plus input-sdl'
@@ -34,8 +34,8 @@ function sources_mupen64plus() {
if isPlatform "rpi"; then
repos+=(
'gizmo98 audio-omx'
- 'ricrpi video-gles2rice pandora-backport'
- 'ricrpi video-gles2n64'
+ 'psyke83 video-gles2rice pandora-backport'
+ 'psyke83 video-gles2n64'
)
else
repos+=(
gles2n64 shows a black screen with current binaries - fixed
rice segfaults - fixed
I'm still working on GLideN64.
BTW, I'm seeing an odd issue on jessie; mupen64 won't launch:
message to log
Parameters:
Executing: /opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-n64 "/home/pi/RetroPie/roms/n64/Super Mario 64 (U) [!].z64"
__ __ __ _ _ ____ _
| \/ |_ _ _ __ ___ _ __ / /_ | || | | _ \| |_ _ ___
| |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|
| | | | |_| | |_) | __/ | | | (_) |__ _| __/| | |_| \__ \
|_| |_|\__,_| .__/ \___|_| |_|\___/ |_| |_| |_|\__,_|___/
|_| http://code.google.com/p/mupen64plus/
Mupen64Plus Console User-Interface Version 2.5.0
UI-Console: attached to core library 'Mupen64Plus Core' version 2.5.0
UI-Console: Includes support for Dynamic Recompiler.
Core: Goodname: Super Mario 64 (U) [!]
Core: Name: SUPER MARIO 64
Core: MD5: 20B854B239203BAF6C961B850A4A51A2
Core: CRC: 635A2BFF 8B022326
Core: Imagetype: .z64 (native)
Core: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
Core: Version: 1444
Core: Manufacturer: Nintendo
Core: Country: USA
UI-Console Status: Cheat codes disabled.
UI-Console Error: Specified Video plugin not found: mupen64plus-video-n64.so
Core Status: Rom closed.
If I manually execute the same command:
/opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-n64 "/home/pi/RetroPie/roms/n64/Super Mario 64 (U) [!].z64"
...it fails with the same error if the current directory is /home/pi... but works if I'm in ~/RetroPie-Setup. Not sure if that's related at all to the changes, though.
It's definitely due to a difference in the libraries:
Using the new SDL2 + current binaries:
Works:
SDL_VIDEO_EGL_DRIVER=/opt/vc/lib/libEGL.so SDL_VIDEO_GL_DRIVER=/opt/vc/lib/libGLESv2.so /opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-n64 "/home/pi/RetroPie/roms/n64/Super Mario 64 (U) [!].z64"
Broken (the default configuration in rpi-2.0.6, but to illustrate that it makes a difference):
SDL_VIDEO_EGL_DRIVER=/opt/vc/lib/libbrcmEGL.so SDL_VIDEO_GL_DRIVER=/opt/vc/lib/libbrcmGLESv2.so /opt/retropie/emulators/mupen64plus/bin/mupen64plus.sh mupen64plus-video-n64 "/home/pi/RetroPie/roms/n64/Super Mario 64 (U) [!].z64"
My recommendation is that the remaining packages are moved to the new library names ASAP to fix the issue.
If there's any applications that can't be rebuilt from source (closed source?), SDL 2.0.6 can still work in conjunction with the two environment variables above.
Four PRs needed to fix mupen64plus:
gonetz/GLideN64#1624
mupen64plus/mupen64plus-core#428
ricrpi/mupen64plus-video-gles2n64#24
ricrpi/mupen64plus-video-gles2rice#14
With the four PRs applied, mupen64plus (and all plugins) work correctly on both jessie and stretch with SDL 2.0.6.
Everything has an override for the VC4 driver, too.
P.S. Should we be using any of the official video repos instead of these forks? https://github.com/mupen64plus?utf8=%E2%9C%93&q=video&type=&language=
mame4all-pi:
RetroPie/mame4all-pi#6
This integrates the custom bcm_host/dispmanx code, so it's also not suitable for VC4 support.
When this and the mupen64plus PRs are merged, all software from core + main should be converted to the new libraries (but RetroArch won't work until the script bumps it past v1.6.7 and EmulationStation needs the patch cherrypicked from master to stable).
I'll take a look at the optional and experimental packages next.
@joolswills
Do you plan to update RetroArch to version > v1.6.7 in the near future. I think lr-mupen64plus, lr-parallel and lr-ppsspp should be only updated if the latest RetroArch version is present.
This is a complete list of the optional packages referencing libGLES, and hence that will need changes:
Binary file /opt/retropie/emulators/atari800/bin/atari800 matches
Binary file /opt/retropie/emulators/coolcv/coolcv_pi matches
Binary file /opt/retropie/emulators/gpsp/gpsp matches
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
Binary file /opt/retropie/emulators/pisnes/snes9x.gui matches
Binary file /opt/retropie/emulators/pisnes/snes9x matches
Binary file /opt/retropie/emulators/ppsspp/PPSSPPSDL matches
Binary file /opt/retropie/emulators/reicast/bin/reicast matches
Binary file /opt/retropie/emulators/rpix86/rpix86 matches
Binary file /opt/retropie/libretrocores/lr-mupen64plus/mupen64plus_libretro.so matches
Binary file /opt/retropie/libretrocores/lr-parallel-n64/parallel_n64_libretro.so matches
Binary file /opt/retropie/libretrocores/lr-ppsspp/ppsspp_libretro.so matches
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 going through the list, sending PRs. Until they're all sent, SDL 2.0.6 will not work with any of the above (if SDL applications), unless you set these environment variables:
SDL_VIDEO_EGL_DRIVER=/opt/vc/lib/libEGL.so
SDL_VIDEO_GL_DRIVER=/opt/vc/lib/libGLESv2.so
But setting these globally will break programs that have already been switched to the new libraries.
@gizmo98 When the new RetroArch is released I plan to switch to it.
Regarding library changes - if mupen64 switches to the new library names, will it not work with the older sdl 2.0.5 ? I reverted the SDL 2.0.6 for now.
I would have though the libraries would have been the same (just new names). Wonder what the difference is that causes them to not work - can it just be due to the name change or do you think there are actual incompatible differences ?
Regarding the new library names, here's what's left to be changed from core, main & opt:
Misc:
- caprice: KaosOverride/CapriceRPI#5 (needed to build successfully on stretch, not related to broadcom libs)
- retroarch: already committed, will be applied in next tag or master branch.
PRs/patches that need to be delayed (waiting for retroarch)
- lr-ppsspp: RetroPie/ppsspp#2
- lr-parallel-n64: libretro/parallel-n64#469
- lr-mupen64plus: libretro/mupen64plus-libretro#39
PRs/patches sent, but also need "newbrcmlibs" flag due to SDL2:
- cannonball: djyt/cannonball#29
Currently incompatible with stretch (binary-only):
- giana
- coolcv
- rpix86
I've only sent PRs that are verified working fine on jessie and stretch. Is it ok if I send PRs for SDL2 apps (cannonball and ppsspp)? Once merged, I'll follow up with a PR to add the newbrcmlibs flags.
please do.
Hello,
we'll be having local OSS conference in about 2 weeks and we'd like to have kid's corner here with some retro gaming fun, open movies, etc. I've had RetroPie running on my pie, and have been patiently waiting for stretch support, but it now puts a little deadline on me. So'd like to ask, if i should keep waiting, and it should be ready in those couple of weeks, or if I should buy new SD card just for this.
Thank you!
P. S. No pressure. ;)
Reading this for sometimes already, why not implementing simple check at the beginning of the setup to check which OS version is running then branching it to sub-setup script accordingly.
One will use old existing method while the other will use Stretch new method than trying to make it compatible for both versions.
If all people (eventually) upgraded to Stretch then you can remove the check & Jessie sub-setup.
Just my 2cents....
@CrescendoFang I don't know what you mean by that.
It means separating the Jessie & Stretch code to speed up the process since there's so many changes in Stretch.
So, if the user still using Jessie then the called installation script is for Jessie, Stretch for Stretch.
But there'll be more work to maintain both branches.
START > OS ver? > Jessie > install RetroPie using existing script > END
START > OS ver? Stretch > install RetroPie using updated script pointing to updated drivers/libraries in Stretch > END
@CrescendoFang it doesn't really work like that. It's not just about script changes. We already have a workaround - just @psyke83 is still testing Stretch compatibility (which is much appreciated as I've been short on time).
SDL1 on stretch is using mismatched Debian source. Would this be acceptable for a PR? master...psyke83:sdl1_stretch
This will allow to build different against the appropriate sources on jessie vs stretch, and should make things slightly easier to maintain if there's an upstream bump for either. It adds a little bit more complexity in order to make future maintenance easier.
It will change the resulting package names (bumps +1 and adds "~rpi1 ~jessie", etc.), but keeps packages held, so we will notice when the original packages need updating.
Another issue on stretch is that libpng12-dev is uninstallable due to conflicts with libpng-dev. This is causing link errors in caprice.
Would you accept this PR to the script (not exactly as below - I'll isolate to stretch)?
diff --git a/scriptmodules/emulators/capricerpi.sh b/scriptmodules/emulators/capricerpi.sh
index e1af0df5..c2cf9267 100644
--- a/scriptmodules/emulators/capricerpi.sh
+++ b/scriptmodules/emulators/capricerpi.sh
@@ -22,6 +22,7 @@ function depends_capricerpi() {
function sources_capricerpi() {
gitPullOrClone "$md_build" https://github.com/KaosOverride/CapriceRPI.git
+ sed -i src/makefile* -e s/-lpng12/-lpng/g
}
function build_capricerpi() {
or should I send upstream? I'm not sure about the latter option in this case, as it seems to be a distro-specific issue to stretch.
it should link against png not png12 on jessie also really so I think it should go upstream.
I'm going to start building stretch binaries over the next few days btw.
OK, I'll send the capricerpi change upstream.
RE: stretch & gcc 6, there are two projects in "opt" that fail (not due to the narrowing issue) - lr-armsnes and alephone. I believe that they should build OK if you stick with the default gcc version for stretch (4.9.2-10). I haven't even had time to start looking at the experimental packages.
I thought gcc 6.x was the default - maybe I remember wrong ? Ideally I would like to move to gcc 6.x anyway due to compiler bugs in 4.x (and should be able to remove this hack then too - https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/system.sh#L96)
Yes, I might be wrong. I thought that I had to manually install gcc 6, but I'm not certain anymore. I'd need to reinstall from a fresh lite image to be sure.
https://packages.debian.org/stretch/gcc
Edit: crap, sorry. I pasted a log from a jessie install by accident. It's probably gcc 6 by default on Raspbian stretch (it is on plain Debian stretch).
Hi, anyway I can help ?
At the moment, with Raspbian 9.1, with the standard install procedure, it tells me that Debian Stretch is not yet supported on the RPi .
@Yannovitch Just comment this if https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/system.sh#L78
I cannot manage to complete the Retroarch build though :-(
This is not yet ready for user testing. Sorry. Please can you use the forum for discussion so this issue keeps on topic of development changes. Thanks.
Is there a timeline on when retropie will be available for Stretch? @joolswills
No timeline.
This adaptation is really slow :/
Please do not use this issue for anything other than code discussion. Thanks.
would be cool if we didn't need to have different (older) versions of raspbian to install retropie next to some other packages.. everybody could also just skip stretch and jump on the next one in 2019 or so.. and deal with older versions of packages :p
allright sorry for the sarcasm, i do really appreciate the effort put into this!
This issue needs a fair bit more urgency now the Pi 3 B+ is shipping, and it doesn't boot from Jessie-based v4.3.
The issue does not need more urgency.
Stretch support is basically complete now - we are doing final testing etc. You can use the beta image from the forum - https://retropie.org.uk/forum/topic/16307/retropie-4-3-15-stretch-images-for-testing
Good show, that image booted on the Pi 3 B+ just fine. Thanks for putting in the work.
Closed as stretch support is included in RetroPie-Setup - new official images will be released as soon as I'm ready.
Attempting to boot RetroPie v4.3 on a Raspberry Pi 3 Model B+ will hang on the rainbow screen. Until the official image is updated, Model B+ users have two options:
- Do a manual install over Raspbian Stretch.
- Install the beta RetroPie image.
I think there must be a bit of confusion - the libraries are definitely missing on stretch. I downloaded a lite image to check and it's the same as a dist-upgrade from jessie. The needed libraries are not part of libraspberrypi0 or libraspberrypi-dev.
@joolswills
I think that libgles2-mesa and libgles2-mesa-dev needs to be added as an ES dependency. I'm fairly sure that on jessie, /opt/vc/lib/libGLESv1_CM.so was already a symlink to libGLESv2.so, so you can either recreate the symlink in /usr/lib/arm-linux-gnueabihf or (probably better), edit the ES's FindOpenGLES.cmake so that it also searches for the v2 library directly:NAMES GLES_CM GLESv1_CM GLESv2
OR, if the libgles2-mesa libraries aren't compatible, this may be the solution?
NAMES GLES_CM GLESv1_CM GLESv2_static
That will use /opt/vc/lib/libGLESv2_static.a which is still part of libraspberrypi-dev.
hello, I'm having this exact same problem, can you please help me.
You're already being helped on the forum. This issue is unrelated.