Building GCC as a Cross Compiler for Raspberry Pi
solarianprogrammer.com
solarianprogrammer.com
crossdev -t armv7a-hardfloat-linux-gnueabi
crossdev -t x86_64-w64-mingw32
* https://wiki.gentoo.org/wiki/Crossdev
* https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creat...
apt install gcc-arm-linux-gnueabihf # Debian / Ubuntu
dnf install gcc-arm-linux-gnu # FedoraBut as soon as I wanted to compile my own binaries, things weren't so easy anymore. The glibc on there is too ancient for modern cross-compilers (like the one installed by apt). It can't be replaced because the kernel is too ancient for a modern glibc. Replacing the kernel would probably fail due to lack of compatible drivers.
The sources for the original cross-compiler, the kernel and various libraries were actually quite easy to find on Amazon's website, but they were incredibly difficult to build. Because that GCC used some GNU C extensions that changed semantics in modern GCCs, it didn't even compile without patching the source. The build step for glibc involved filtering the assembly produced by the compiler through a sed script, which of course silently failed when the newer compiler produced different output.
All in all, it took me about two weeks of experimentation until I had a working cross-toolchain.
There are probably at least a couple of other people who might find it usefl.
(Just in case you didn't get the allusion: https://quoteinvestigator.com/2015/08/28/fish/)
Teach me how to build a compiler binary, and I'll be building compiler binaries for a lifetime.
which is somewhat less inspirational. Even less so when replacing "compiler binary" by "other people's code".
I think the main problem with your analogy is that in IT, the "fish" are free.
> the "fish" are free
That's true. But if you know how to build them you can make new kinds of fish. That can come in handy if you don't like the free fish.
By 1) minimising the times you need to compile yourself 2) making it easy to compile yourself (e.g. easier than autoconf/automake but even those are examples which have said goal in mind).
> That's true. But if you know how to build them you can make new kinds of fish. That can come in handy if you don't like the free fish.
Its not difficult to learn how to make these new fish, but learn it when its the best or required (ie. only) solution.
A better analogy is that you have a hammer at your disposal, but you refuse to use it because when you learn to use your feet instead that's a useful practice. Its not; its only useful the time you don't have a hammer (which you usually have around). Instead, try to keep your hammer with you.
;)
Apt or dnf or some other package manager (like yum or pacman) comes preconfigured and preinstalled on all but the most esoteric Linux distros, so unless you're doing some really esoteric stuff, if you're fighting with dependencies, I would assume something's gone wrong.
Which is to say, it still certainly possible to fall into dependency hell in this day and age, but the parent response belies a certain level of fear of installing things on Linux because of dependencies. I hear Windows still has this problem, decades later, and while Linux has it's own share of foibles, installing pre-packaged software is generally not the exciting/frustrating part. (Which Docker has made even easier!)
and as a developer who primarily develops on windows, windows itself doesn’t have any “dependency” problem really. it’s all the people who basically write their software on and for linux and then haphazardly try to make it work on windows through a series of hacks while claiming support for windows.
when you come across maintainers who take both linux and windows seriously, you just run an installer and get on with your life.
Then again, the more esoteric the platform, or the less frequently a particular piece of software is wanted on that platform, the more friction you'll have to overcome.
Find a Windows for MIPS (or whatever that embedded Linux is running on) and tell me that getting equivalent software running is easier.
The learning curve is quite steep though. For Raspberry Pi this is an excellent getting-started guide: http://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.ht...
The worst thing about cross-compiling Qt is that I always run into different issues with new releases, and it's not even always consistent between builds. I ended up renting a 64 core VPS to build Qt so that I could iterate faster though build failures, but it's still at least half a day's work to get it to build properly.
Also: I'm assuming the 64 core machine is ARM? Which provider do you use for that?
It might be helpful though for 64 bit ARM, but my target architecture is 32 bit and because I need webengine I suspect that it will not compile on a 32 bit platform. The problem is that the linker requires more memory than can be addressed in a 32 bit address space for linking chrome/webengine.
I just used google cloud.
I'm actively trying to replace GCC+binutils for llvm based tools in Android (and further, at Google). Currently working through some issues for the kernel, more so llvm's assembler and linker than Clang.
I tried various solutions like Qemu, but the performance was about the same as a real Pi.
I would recommend building a cross-toolchain by hand just a couple of time to understand the whole process, but then just use ct-ng or something similar: it gets the job done and it's very configurable (abi, target architecture, libraries etc).