Cross-compile Recalbox
-
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.
-
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.
-
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
-
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.
-
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:)
-
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.
-
Cool, looking forward to review your pull request
-
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.
-
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.
-
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 ?
-
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.
