I suppose you can count me in if you like.  I'm D3m0n1q733rz. I'm curious to see if this version of Recalbox will include the most recent version of Binutils.  One of the biggest problems I had was getting it to compile binutils with gold and plugin support for LTO.  It would have sped things along.  It took me a while to figure out to include the flags in the configuration for Binutils, LD and GCC, and the rest in the actual make command line.  Perhaps we could include a method to include all flags for used (pre)compilers in the configuration file with support for ${foo} to copy GCC flags to things like Graphite, LTO, FD, etc. Well, I can't promise how much help I'll be outside of compiling.  I've been more focused on Binutils and helping get those bugs out, but I had been trying to optimize this compilation a few times for better speed in certain emulators otherwise considered dramatically slow or stuttery. Might I recommend trying to profile the runtimes of some of these programs for further optimization on a recompile via -fprofile-generate --fprofile-dir=profile and --fprofile-use on pre-builds?  It's just a thought.  The only issue is that we won't end up using the entire program on some profiles, so it will help minimally. Anyway, that's my two cents worth.  I'll look forward to helping out on anything with this project. Thanks!

Yawn...sudo then the command...Yawn

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.

I suppose you can count me in if you like.  I'm D3m0n1q733rz. I'm curious to see if this version of Recalbox will include the most recent version of Binutils.  One of the biggest problems I had was getting it to compile binutils with gold and plugin support for LTO.  It would have sped things along.  It took me a while to figure out to include the flags in the configuration for Binutils, LD and GCC, and the rest in the actual make command line.  Perhaps we could include a method to include all flags for used (pre)compilers in the configuration file with support for ${foo} to copy GCC flags to things like Graphite, LTO, FD, etc. Well, I can't promise how much help I'll be outside of compiling.  I've been more focused on Binutils and helping get those bugs out, but I had been trying to optimize this compilation a few times for better speed in certain emulators otherwise considered dramatically slow or stuttery. Might I recommend trying to profile the runtimes of some of these programs for further optimization on a recompile via -fprofile-generate --fprofile-dir=profile and --fprofile-use on pre-builds?  It's just a thought.  The only issue is that we won't end up using the entire program on some profiles, so it will help minimally. Anyway, that's my two cents worth.  I'll look forward to helping out on anything with this project. Thanks!

It also depends on if you're using a filesystem capable of compression.  If you are, you can use a smaller card and still hold a lot of data.  It's like putting your entire filesystem in one big zip file.

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.

3.0.0 will work on the RPi3, but won't be able to take advantage of all of its features outright.  If you can compile for the Pi2, it will at least work.  Otherwise, you'll need to recompile for the Cortex-15 and hope it works.

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.  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.

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.

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.

You're missing the bluetooth driver setup.