In https://unix.stackexchange.com/a/141619/674

I wouldn't store just the makefile. While the uninstall target may not (or perhap, should not) need anything else to succeed, that's not a guarantee.

So that means keeping a copy of the original package. There's not much point, though, if there's a public archive of old versions and you aren't worried about it going away. You can just download it again later anyway. The only issue with this is that for autotooled stuff you need to run ./configure first, and if you use different options uninstall may miss something -- but that's not such a big worry, I think. Occasionally I've kept notes about the particular configuration of something.

I keep independent source packages in /usr/local/src, but it as long as you can find it when you need it, it doesn't matter.

Why is it that "for autotooled stuff you need to run ./configure first, and if you use different options uninstall may miss something"?

What is the reason that the configure file is required for uninstalling an application installed via configure, make and make install?


1 Answer 1


Suppose the package has an --enable-foo configure option that causes it to build its foo subsystem and install libfoo.a in …/lib and a foo executable in …/bin. So you install that and clean up your temporary build directory.

You then come back months later, and unpack the package tarball afresh in order to uninstall it. You need to rerun ./configure to reconstruct the makefiles so that you can do make uninstall, and if you don't configure with --enable-foo then the commands to build/install/uninstall libfoo.a and foo may not be included in the respective make targets. In which case, make uninstall would miss cleaning up libfoo.a and foo.

It would be worth preserving config.status from the original installation's build directory, as that records the configure options used.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .