Many people here rant about the dependency hell (rightly so). I'm doing systems programming for quite some time now and it changed my view on what I consider a dependency.
When you build an application you usually have a system you target and some libraries you use that you consider dependencies.
So the system is basically also a dependency (which is abstracted away in the best case by a framework).
What many people forget are standard libraries and runtimes. Things like strlen, memcpy and so on are not available on many smaller systems but you can provide implementations of them easily. Things like malloc are much harder to provide. On some system there is no heap where you could dynamically allocate from so you have to add some static memory to your application and mimic malloc allocating chunks from this static memory. Sometimes you have a heap but you need to acquire the rights to use it first. malloc doesn't provide an interface for this. It just takes it. So you have to acquire the rights and bring them magically to malloc without the actual application code noticing. So even using only the C standard library or the POSIX API can be a hard to satisfy dependency on some systems. Things like the C++ standard library or the Go runtime are often completely unavailable or only rudimentary.
For those of you aiming to write highly portable embedded applications please keep in mind:
- anything except the bare language features is a dependency
- require small and highly abstracted interfaces, e.g. instead of malloc require a pointer and a size to be given to you application instead of your application taking it
- document your ABI well because that's what many people are porting against (and it makes it easier to interface with other languages)

Linux is great - to tinker, to pull in all your FOSS, mess around...
But it's so fucked up, if you actually build and maintain a product on it, i.e. try to distribute s.th. in binary for money even. It's just not intended. If you offer your code for free, you can always say: "Ah, just compile it yourself. You might need these 29 dependencies, of which 2 are not even checked by configure, oops, and now it crashes, maybe in that qt library version, you picked there's still a bug?.. you know, it worked on my machine, sorry."
But if you sell it, it better install and run! And even if you target only the main distros of all that fragmented Linuverse - let's say, Debian, Ubuntu, RHEL, CentOS, Fedora, and if you're in Germany OpenSuSE and SLES, you'll start to see the crap of work you're up with. What you could try is to orchestrate a docker fleet with one container per distro, where you take the oldest version you still support compile a newer gcc there (to at least have C++11) and all your third party libs and then hope the resulting binary runs on all the newer versions of that distro, too.
(You could even be so brave as to try to pick a deb and rpm distro to build for all other distros.)
But ABI incompatibility can still bite you. For instance we once had the insane case, that our GUI would no longer start just by switching the Window-Manager to KDE.