In practice, I've spent many awful hours chasing libtool breakage on even the most common
libtool adds extreme complexity to packages in an attempt to make them build everywhere. More
software means more bugs. The end result is preductable: libtool packages often fail to build
on even the most common platforms.
First you need to track down and install the exact version of automake used by the packager,
twiddle the configure file to remove syntax errors, try to figure out the magic combination of
undocumented --enable and --disable switches that will actually compile, and so on... This
whole process is more abstract and opaque than editing Makefiles directly, but is it better?
Does it actually save time?
libtool is a bad abstraction. Like CORBA, it tries to gloss over horrifyingly complex
problems but, instead of solving them, it seems to just push them around. Perhaps I'm getting
philisophical, but I think they too hard to insulate the user from the real world. D-Bus
doesn't try as hard as CORBA and, as a result, it's much more usable and reliable. And a heck
of a lot smaller. I feel like libtool could learn the same lesson.
I worked as a release engineer, so I admittedly had to wrestle with libtool a lot more than
the average person. The missing ' in configure was the winner; finding that that took 7 hours
of binary searching an unreadable 350K shell script. For comparison, it takes 3-4 hours to
learn how to use cmake from scratch! libtool solves some problems, creates others, and the
end result seems to be a wash.
Anyhow, that's just my experience. Not good. Allow me to cast my vote for a simpler libtool
in the future.