zapper wrote:I think if I reply here maybe someone will help you. So here's hoping that works.
Thanks. I think I might be able to actually solve the issue on my own. When starting this topic, I was already suspecting what the problem is.
In case some less-technical ppl come across this - here's the problem:
Gcc interacts closely with the C library (not just the libc, but also libpthread and many others bundled with it). Aside from explicit calls to libc functions in C programs, compiler often has to generate calls on its own. But to be able to do this, the compiler needs a lot of information about libc & friends. It gets it from their header files and shared libs (and ar archives?). Unfortunately, all those must be available when gcc is being built. It causes a bit of a problem when building a cross-compiler. Development libraries for architecture X are a build dependency (often called make dependency in Arch world) of a cross-gcc targeting X. But to build these libraries (libc & friends) for architecture X, you need an already working cross-compiler. So we have a circular dependency (chicken and egg problem): cross-gcc requires libraries, that require cross-gcc, and so on.
The solution to boostrapping this is to first build a minimal cross-gcc (called 'base' or 'pass1'), that has no information about c library for the target architecture and is unable to build programs against it. It is, however, able to build the libc (& friends), which, when built, can be used for building the actual fully-working cross-compiler (called 'pass2') with all extra features and languages enabled.
Different tutorials/wikias/scripts give a bit different order of cross-toolchain bootstrapping, but it's something like:
binutils → gcc (pass1) → linux api headers and glibc → gcc (pass2)
Arm development libraries package doesn't exist in Hyperbola/Arch. The arm-unknown-linux-gnueabi-gcc package in Hyperbola is built without these libs (as would a minimal pass1 compiler be), but has "the features" enabled in arguments to configure script (as would a pass2 compiler). It also doesn't depend on its respective arm binutils (it does depend on standard binutils, which won't do). All summed up, this build of gcc can't be used for cross-compiling arm glibc. This topic shows what happens.
Gcc PKGBUILDs in the AUR/Arch seem to also have similar problem(s). arm-linux-gnueabi-gcc is only a pass1 compiler, no PKGBUILD for later steps (maintainer is aware of it). arm-linux-gnueabihf-gcc has a bootstrap chain with 3 builds of gcc instead of 2. arm-none-eabi-gcc has a circular dependency with arm-none-eabi-newlib. It works, but cannot be easily bootstrapped. mingw-w64-gcc seems ok. Its pass1 gcc package has a -base suffix. It's a bit different, however, because it targets Microbugs' Windows instead of a GNU/Linux platform (in fact arm-none-eabi mentioned above isn't a GNU/Linux target either).
It seems that debian does it a better way. It has the cross-toolchain-base source package, from which target platform libraries and headers packages are built. No separate pass1 gcc package exists - looks like it gets built in a temporary directory as part of the cross-libc build. Sources of gcc, binutils, etc. are provided as separate packages, so packaging tools don't attempt to download them every time.
I'm going to open an issue about that in a few hours.
EDIT: I opened an issue. It has all the fields (severity, category, etc.) set wrong, because when I first clicked to submit, I got an error (regarding too long tags field for an sql datatype), had to refill the form and forgot to set the fields again... Now I can't edit it ;_;
EDIT2: Turns out when I first got the error, the issue actually got uploaded, just without tags. https://issues.hyperbola.info/index.php … sk_id=1399. I can't edit/delete this one either 
Sorry for that. Some1 please delete the duplicate.
