Why bother?
apt install gcc-arm-linux-gnueabihf # Debian / Ubuntu
dnf install gcc-arm-linux-gnu # Fedora 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.