Cross-compile Recalbox

[d3m0n1q733rz]

Hello, I was trying to find some help on cross-compiling Recalbox on Ubuntu 64-bit.  I, however, have only found tutorials for compiling kernels and the like which are really of little help.  I was wondering if someone who is familiar with cross-compiling from Ubuntu to ARM would be willing to give me the make command to successfully tell the system that I am cross compiling for armv7ve so that my GCC, GCPP, GC++, Gfortran, Graphite, LTO, etc. can properly recognize that it is cross-compiling to ARM instead of native.  I've tried adding the ARCH=armv7ve flag, adding the CC=arm-linux-gnueabihf, etc. but it won't seem to crosscompile properly.  I can give a list of the error it encounters later (when I'm at my own PC), but I really want to get this to use thumb-interwork, graphite, and LTO to optimize binaries and use busybox in place of bash for a little less overhead. Would someone please assist me without calling me a ricer?  I've already setup my .config file via kconfig (I prefer it or gconfig to menuconfig).  So it should work past that point.  I just need to get it crosscompiling and the RPi2 doesn't seem to be able to do so as the card gets taxed quickly with all of the reads and writes it's doing constantly. Thank you, D337z

[d3m0n1q733rz]

Okay, so after a while, I had come up with this as my command as ${FLAGS} wasn't working, I had to write out previous flags options to share them with other flags.  I have four cores that I'm trying to use on my host PC, so don't think it's just because of the RPi2. make -j4 ARCH=armv7ve CC=arm_linux_gnueabihf CPUFLAGS="-m32 -mthumb-interwork -mcallee-super-interworking -mcaller-super-interworking" GRAPHITE="-mthumb-interwork -mcallee-super-interworking -mcaller-super-interworking -m32 -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity" CPPFLAGS="-m32 -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -O3 -fuse-ld=gold -mtls-dialect=gnu2 -flto=4 -pipe -fuse-linker-plugin -ffat-lto-objects -freciprocal-math -ftree-vectorize" CFLAGS="${CPPFLAGS}" CXXFLAGS="${CFLAGS}" LDFLAGS="${CFLAGS} -fuse-linker-plugin" USE="graphite lto" The errors that come about are: /bin/bash: arm_linux_gnueabihf: command not found Makefile:702: recipe for target 'array.o' failed make[4]: *** [array.o] Error 127 make[4]: *** Waiting for unfinished jobs.... /bin/bash: arm_linux_gnueabihf: command not found Makefile:702: recipe for target 'builtin.o' failed make[4]: *** [builtin.o] Error 127 /bin/bash: arm_linux_gnueabihf: command not found /bin/bash: arm_linux_gnueabihf: command not found Makefile:702: recipe for target 'awkgram.o' failed make[4]: *** [awkgram.o] Error 127 Makefile:702: recipe for target 'cint_array.o' failed make[4]: *** [cint_array.o] Error 127 Makefile:742: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 Makefile:562: recipe for target 'all' failed make[2]: *** [all] Error 2 package/pkg-generic.mk:195: recipe for target '/home/d337z/Desktop/Work/recalbox-buildroot-rpi2/output/build/host-gawk-4.1.3/.stamp_built' failed make[1]: *** [/home/d337z/Desktop/Work/recalbox-buildroot-rpi2/output/build/host-gawk-4.1.3/.stamp_built] Error 2 Makefile:36: recipe for target '_all' failed make: *** [_all] Error 2 It's not an error with the program itself as far as I can tell, but I wouldn't mind knowing what I'm doing wrong and what I should try to do it right.  I have the programs installed as best I can tell.  Synaptic shows everything involving gnueabihf is installed.  So I'm at a loss here. I'm really thinking that I can contribute to this project so much if I can just figure out this darn cross-compiling thing. Well, thanks!

[d3m0n1q733rz]

So, anyone know the proper command to cross compile with GCC 5?  I've got the cross-compiler downloaded, just need to get the command to use it properly.  Sorry to b*mp like this, but I see a lot of comments on other topics but none on mine.  So I'm just a little antsy. Thanks!

[Substring]

recalbox is not made nor made to be cross compiled to anything else than a Pi. You can natively compile ES, emulators, anything, but not the system itself.

[d3m0n1q733rz]

I'm using the Pi as the target system and the desktop as the host.  So I think you're a little confused about what I'm doing.  I'm compiling it on my desktop to run on the pi.  It can work as it's the software that matters.  While I do appreciate your response, I'm just looking to compile with the bigger computer with more RAM to work with and the faster processor with more cores to run it on the little RPi2 and 3 which I can't use to compile on due to my card erroring under the strain of frequent reads and writes for hours on end.  Even more so when I create a swap file outside of using zswap. I know what I'm doing and that it can work, but not sure how to setup the command to do it.  I believe I need to set target and host system flags in make to do so.   Edit:  Also, I believe it's also made to port to Beaglebone.  But that's going off of config options.

[digitaLumberjack]

Why don't you compile with buildroot ? https://github.com/recalbox/recalbox-os/wiki/Compilation-&-Modifications-(EN) the tutorial is a little bit obsolete but you can find the big idea. Second solution, we just made a docker to build recalboxos really eaysily : https://github.com/recalbox/recalbox-docker-build

[d3m0n1q733rz]

Why I don't just build with buildroot: "I just need to get it cross-compiling and the RPi2 doesn’t seem to be able to do so as the card gets taxed quickly with all of the reads and writes it’s doing constantly." And docker doesn't do what I need it it. As far as I can tell, I should just have to set the host and target system flags in make so that I can point it to the cross-compiler version of gcc and binutils.  It should be able to do the rest.

[digitaLumberjack]

Sorry I don't get your problem. You want to cross compile and build root is just a cross compile tool. Docker just make it even more easy. You would have compiled the whole system right now:)

[d3m0n1q733rz]

Okay.  I guess I had mistakenly thought that it was for only building on the native system.  Can it take CFLAGS, LD, and USE flags and the like too?  I'm looking to compile a Thumb based version for the RPi3 to test it's speeds compared to the ARM based.  I'm also wanting to link with gold.ld and use graphite and LTO to smooth things out a bit and remove redundant code. Thank you.

[digitaLumberjack]

Cool, looking forward to review your pull request

[d3m0n1q733rz]

So far, I'm having a difficult time even passing the compile flags to it.  Each flag that I know is supported by GCC for ARM is being rejected at compile time.  I've even tried different ways of typing them out in the menuconfig and even gconfig, but it won't properly pass them to the compilers.  It also seems to only cross-compile the C processor instead of C, C++, and Fortran which are all used to optimally compile many of these programs (though not exactly required).  Is there any way to properly pass the USE, GRAPHITE, CPPFLAGS, CFLAGS, FFLAGS, and LDFLAGS to menuconfig through the toolchain options?  Or is it absolutely only using C?  Even so, there should be a way to pass GRAPHITE flags so that it can know what exactly it needs to do or it's just being compiled for no reason what-so-ever without being used.

[d3m0n1q733rz]

Okay, so a little bit of an update:  I have managed to get it to compile, for the most part, in Thumb2 mode with graphite and lto enabled.  However, I got caught on a small snag involving binutils not accepting plugins for ranlib.  After searching extensively through Ubuntu's apt repositories, I decided to compile binutils 1.26 myself with --enable-gold and --enable-plugins to remedy the situation.  I've had to pass most flags directly through make in order to get them to be accepted as buildroot does not offer much beyond simple target cflags, binutils make flags, and ldflags.  This offers little support for the build of the cross-compiler in the first place beyond what packages will be built. So far, it's coming together, but it's not without its headaches.  If anyone wants to assist me on this, I would gladly welcome it. Enclosed is the .config file (you will need to cp it to your build root as .config) and here is the command I am issuing: make GRAPHITE="-floop-interchange -floop-strip-mine -floop-block -floop-unroll-and-jam -fgraphite-identity -floop-nest-optimize" CFLAGS="-flto-compression-level=9 -flto -fuse-linker-plugin -mtls-dialect=gnu2 -ftree-parallelize-loops=4 ${GRAPHITE}" FFLAGS=${CFLAGS} LDFLAGS="-fuse-ld=gold ${CFLAGS}" CXXFLAGS=${CFLAGS} TARGET_GRAPHITE=${GRAPHITE} TARGET_CFLAGS=${CFLAGS} TARGET_CXXFLAGS=${CFLAGS} USE="graphite lto" TARGET_USE=${USE} TARGET_LDFLAGS=${LDFLAGS} I will either add a -j4 after make or change lto=4 to match my virtual processors later, but I want to check the sorted output for errors as of right now.

[vincent]

Hi I've followed the Wiki for the Compilation on Ubuntu 32 Bit sudo apt-get install build-essential git libncurses5-dev qt5-default qttools5-dev-tools mercurial libdbus-glib-1-dev texinfo zip default-jre imagemagick arch=rpi2 git clone https://github.com/recalbox/recalbox-buildroot.git recalbox-buildroot-${arch} cd recalbox-buildroot-${arch} make recalbox-${arch}_defconfig make After 4 Hours ++ of compilation I'm getting the following error Makefile.gnu:69 : la recette pour la cible « libfreeimage-3.16.0.so » a échouée make[3]: *** [libfreeimage-3.16.0.so] Erreur 1 Makefile:21 : la recette pour la cible « default » a échouée make[2]: *** [default] Erreur 2 package/pkg-generic.mk:195 : la recette pour la cible « /home/vincent/recalbox/recalbox-buildroot-rpi2/output/build/freeimage-3.16.0/.stamp_built » a échouée make[1]: *** [/home/vincent/recalbox/recalbox-buildroot-rpi2/output/build/freeimage-3.16.0/.stamp_built] Erreur 2 Makefile:36 : la recette pour la cible « _all » a échouée make: *** [_all] Erreur 2 Do you Know The reason ?

[d3m0n1q733rz]

No, sorry.  It's all French to me.  But you should look at using more threads for your compilation with the -j flag after make.  For example, on a 4 core processor, make -j4 would take roughly 1/4 of the time to run.  It wouldn't do any good on a single core though. Anyway, after a little research, it's possible that it's a compilation flag error involving ANSI.  I'm not sure how to fix it in this setting as we're using the same settings to compile multiple different programs all at the same time and this one would require a special setting that's not run by default.  I would just recommend suggesting it be fixed to the creators.