It also generates “.la” files, which you’ll see scattered in your /usr/lib. These are used to track dependencies of shared libraries. If project P depends on library L which uses library L2, then on some platforms (HPUX is the example, I think) P needs to be built with both -lL and -lL2. This is yet another good thing libtool handles.
But! Recent operating systems, including Linux, handle the dependency problem themselves, and libtool takes a lot of time to process. LogJam takes almost ten seconds to link (that’s link, not build; ten seconds just to stitch the .o’s together) on my laptop, and nearly half of that time is spend in libtool where it’s just calculating the actual link line for gcc. So here’s the trick: you can just rm those la files (I mv them into /usr/lib/la) and things will work as before, but noticeably faster. This solution came from Owen Taylor of GTK+, someone who really knows the gory details of libraries, so it’s pretty safe.
* This is actually important, because it means you can run a program that depends on shared libraries without installing it; libtool fixes up the library paths. But it thwarts running the debugger, because you no longer have a binary. What to do? “libtool gdb ./scriptexecutable” does what you want.