© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I just had a chat with the retroarch guys on IRC, unfortunately it seems they do not have a mailling list.
<plugwash> Hi guys, I am the maintainer of Raspbian, recently a bug report regarding retroarch in Raspbian dropped in and I could do with some advice.
<orbea> plugwash: what is the bug report?
<plugwash> https:/
<retrobot> Title: Bug #1734592 “retroarch returns “illegal instruction"" : Bugs : Raspbian
<orbea> plugwash: this is 1.3.6?
<hunterk> ah, yeah, could be related to the NEON flag
<plugwash> orbea, yes
<plugwash> So my questions
<orbea> plugwash: any way you can update it and see if it still occurs?
<orbea> 1.3.6 is kind of old :)
<orbea> 1.6.9 just came out recently
<orbea> i mean there is not much point in fixing something that might already be fixed? :)
<hunterk> I know debian likes to use super-old packages, which is fine, but seeing if it's already fixed would indeed keep us from reinventintating the wheel
<plugwash> So anyway my questions
<plugwash> 1. Is there an easy way to tell the retroarch build system not to hide the commands it is running
<plugwash> 2. Is retroarch supposed to support runtime detection of neon?
<orbea> yes, but gimme me a moment to remember exactly how
<hunterk> I don't think we do runtime NEON detection, no
<orbea> plugwash: ./configure && make V=1
* ashark has quit (Ping timeout: 240 seconds)
<orbea> pretty sure that existed even in 1.3.6
* seventh has quit (Ping timeout: 250 seconds)
<plugwash> hunterk, thanks for the info, that kinda sucks from the point of view of raspbian since our users are split between neon and non-neon systems
<orbea> plugwash: for neon you need ./configure --enable-neon
<orbea> its set to off by default
<orbea> i can see why that would be problematic..
* Twinaphex has quit (Read error: Connection reset by peer)
<orbea> hacky solution would to ship RetroArch and RetroArch-neon
<plugwash> orbea, right but it's turned on in the Debian packaging (which we have picked up in raspbian). That was why I was trying to find out if retroarch had runtime detection or if "--enable-neon" was intentionally incompatible with non-neon systems.
<orbea> im not sure runtime detection would be ideal either...some distros ship neon regardless if its arm or not
<orbea> see slackware
* ashark (~ashark@
<plugwash> umm neon is an arm extension, neon on non-arm doesn't make sense as a concept.
<orbea> it does if you ship a full install which may or may not be arm
<orbea> package management is pretty different for debian and slackware :P
<hunterk> so what would be a solution? raspbian uses the same package for all hardware?
<orbea> split it into two packages is the easiest I can think of
<orbea> retroarch and retroarch-neon
<hunterk> assuming they only have a single repo
I have built a retroarch package (In a raspbian stretch environment) without neon and would like people to test it.
http://
If it works we can then think about where we go from here.