Compilation

Right, so you’ve just run make install and a few thousand files have silently scattered themselves across your /usr/local like digital confetti. You feel that little pang of regret. “How do I ever uninstall this?” you wonder. “What have I done?” Welcome to the fundamental problem of installing from source. make uninstall is a fickle beast—it only works if the Makefile is perfectly designed for it (many aren’t) and you haven’t rm -rf’d that source directory yet.

Right, so you’ve compiled this beautiful piece of software from source. It was a journey of ./configure, make, and the sweet, sweet sudo make install. You run the new binary, and instead of a triumphant fanfare, you’re greeted with a cold, brutal error: ./my_awesome_program: error while loading shared libraries: libsomethingfancy.so.42: cannot open shared object file: No such file or directory Your program is there. The library it needs exists on your system (probably in /usr/local/lib). So what gives? Welcome to the wild west of shared library management on Linux. The system’s dynamic linker, ld.so, is basically a very picky librarian. It has a strict list of places it’s willing to look for books (shared libraries), and your newly installed library isn’t on that list. Let’s fix that.

Right, so you’ve run ./configure (or maybe cmake ., you rebel) and it didn’t explode. Congratulations. Now you’re staring at a Makefile and the only thing you know to type is make. That’ll work, about 70% of the time. But the other 30% of the time, you’ll be left wondering why the software installed somewhere deeply unhelpful, or why your disk space is mysteriously vanishing. Let’s fix that by understanding what you’re actually telling make to do.

Right, so you’ve run ./configure and it’s asking you for a --prefix. Or maybe you’re just staring at a CMakeLists.txt wondering where this thing is going to end up. This isn’t just some trivial detail; this is you deciding where on your filesystem this new software will live, and that decision has serious consequences for how you manage your system. Get it wrong, and you’ll be living with a minor annoyance for the life of that application. Get it really wrong, and you might hose something important later.

Right, so you’ve downloaded a beautiful tarball of pristine source code. You run ./configure and—oh, look at that—it spews out an error about a missing library. You’re missing a dependency. This is the universal hazing ritual for compiling from source, and it’s about to become your new normal. Don’t panic. This isn’t a failure; it’s just the build system telling you, in its own obtuse way, what it needs for the next step.

Alright, let’s talk about CMake. If you’re compiling from source, you’ve probably run into it. It’s the meta-build system that generates build files for other, less-insightful build systems like Make, Ninja, or Visual Studio projects. Think of it as a polyglot translator for build tools: you tell CMake what you want built in a high-level language, and it writes the low-level, platform-specific instructions for the builder of your choice. This is genius because it means project maintainers only have to write one CMakeLists.txt file instead of a Makefile, an MSBuild file, a Ninja file… you get the idea.

Alright, let’s get our hands dirty. You’ve downloaded a tarball, unpacked it, and now you’re staring at a README that tells you to run ./configure && make && make install. This is the holy trinity of the Autotools build system, a venerable and slightly cranky piece of engineering that has built more of the software you use daily than you can possibly imagine. It’s not magic, it’s a carefully constructed series of shell scripts designed to paper over the insane differences between thousands of Unix-like systems. Let’s break it down so you know what you’re actually doing, not just typing incantations.