Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RetroArch ARM64 support #113

Open
IntelMiner opened this issue May 6, 2018 · 15 comments
Open

RetroArch ARM64 support #113

IntelMiner opened this issue May 6, 2018 · 15 comments

Comments

@IntelMiner
Copy link

Hi,

I added the overlay as part of my Gentoo ARM64 target for the Raspberry Pi

Unfortunately none of the packages seem to have any keywords for arm64 support

replacing ~amd64 with ~arm64 across all ebuilds with sed and doing a rebuild with repoman was sufficient to get most, but not all cores to build correctly

Would it be possible to get ARM64 support added to the relevant ebuilds?

I'm going to be submitting bug reports for the cores that did not build under arm64 to the relevant git repositories within RetroArch itself

@stefan-gr
Copy link
Owner

Sure, if you can make a list of the ones that work then I will add them.

@IntelMiner
Copy link
Author

IntelMiner commented May 7, 2018

Tentative list of cores that compile (but do not necessarily work yet on ARM64) in the libretro-meta package

4do
beetle-psx
bsnes
fbalpha
fbalpha2012
fceumm
gambatte
genplus
handy
mednafen-gba
mednafen-ngp
mednafen-pce-fast
mednafen-saturn
mednafen-snes
mednafen-supergrafx
mednafen-vb
mednafen-wswan
meowpc98
meteor
mgba
mrboom
nestopia
nxengine
parallel-n64
prboom
prosystem
quicknes
sameboy
scummvm
snes9x
stella
tyrquake
vbam
yabause

Bug reports filed

@IntelMiner
Copy link
Author

Numerous cores also seem to exhibit unintended behavior during the configure source phase

using pcsx-rearmed-libretro as an example (with git commit c6e7ce9ef2e39e798dfc0b0fe071064b11b4ca9e )

>>> Configuring source in /var/tmp/portage/games-emulation/pcsx-rearmed-libretro-1.0_pre20180507/work/pcsx_rearmed-c6
./configure --prefix=/usr --build=aarch64-unknown-linux-gnu --host=aarch64-unknown-linux-gnu --mandir=/usr/share/man =libretro
unknown option --prefix=/usr
unknown option --build=aarch64-unknown-linux-gnu
unknown option --host=aarch64-unknown-linux-gnu
unknown option --mandir=/usr/share/man
unknown option --infodir=/usr/share/info
unknown option --datadir=/usr/share
unknown option --sysconfdir=/etc
unknown option --localstatedir=/var/lib
unknown option --libdir=/usr/lib64

@IntelMiner
Copy link
Author

games-emulation/retroarch itself also does not seem to build under ARM64 through the provided package

Removing all patches and attempting to build versions 1.7.1 through 1.7.3 yields the following output

https://paste.pound-python.org/raw/2YsDsGbB1PSkFOKecpnl/

Changing the USE flags seems to cause it to fail during different portions of the configure portion as well

USE="threads" causes it to fail with checking for lthreads

@IntelMiner
Copy link
Author

Interestingly, downloading the 1.7.3 RetroArch sources and doing a straight ./configure && make -j4 && make install seems to build and run without issues

@stefan-gr
Copy link
Owner

Please disable USE "custom-cflags" globally, it really is only intended for advanced testing per package and it can exhibit random runtime and build failures.

@IntelMiner
Copy link
Author

Done and done

I'll try rebuilding the cores that failed to build and update if they compile/run properly after

@stefan-gr
Copy link
Owner

Sorry, I should add some einfo to the eclass to warn users not to use it globally.
Did you remove the patches for retroarch? According to the log it doesn't apply patches for some reason. One of them takes care of unkown configure errors. It's a gentoo specific patch because portage throws what it wants into the configure phase.

@stefan-gr
Copy link
Owner

Ah you did remove them.
The only problematic one should be the fpu patch, please let the others in and post a log.

@IntelMiner
Copy link
Author

Currently doing a full rebuild of all cores, working and non-working

Might take several hours. I'll re-add the patches and rebuild RetroArch after

@stefan-gr
Copy link
Owner

I will add ~arm64/~arm KEYWORDS later today so it should be easier for you to test things further.

@IntelMiner
Copy link
Author

~ARM should be less problematic to build. As I understand it, RetroArch has been extensively tested on at least ARMv6 for the Raspberry Pi

@IntelMiner
Copy link
Author

I went and updated the Layman overlay to get your updated 1.7.3/9999 ebuild

Building with USE="threads" fails with Forced to build with library -lpthread, but cannot locate. Exiting (build log here)

Building without threads also fails similarly with Forced to build with library -lc, but cannot locate. Exiting (build log)

@stefan-gr
Copy link
Owner

It seems it can't find your libc.

Can you search for it on your system and try it again with
append-ldflags -L"${EROOT}"replace/this/with/path/to/libc?
It should normally be in /usr/lib${ARCH}.
Insert it somewhere before econf gets called in src_configure. Somewhere around here should be good:


Just make sure that it sits on the same indentation as the other lines.

@IntelMiner
Copy link
Author

I tried a few permutations of append-ldflags without success

As far as I can tell, libc.so resides in /usr/lib64/libc.so along with libc.a

Appending append-ldflags -L"${EROOT}"/usr/lib64 or append-ldflags -L"${EROOT}"/usr/lib64/libc.so (or libc.a) did not seem to fix the issue

I tried putting it at the same indentation on line 202 as well as directly below src_configure () {

Apologies if I seem a bit clueless on this. I've not extensively worked with editing ebuilds or ARM64 before recently

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants