As far as OpenBSD goes, we solve the `various versions' issue differently. - we have kept the version numbers from old a.out. Our ELF ld.so knows about libfoo.so.major.minor. - if we want several versions installed, it's just a question of having them in distinct directories. ld stops at the first directory where it finds a library.
So, for instance, if you have both qt2 and qt3 installed, you end up with libqt.so.2.0 and libqt.so.3.0 in /usr/local/lib (since ld.so looks at /usr/local by default), and for linking, you have them visible as /usr/local/lib/qt2/libqt.so.2.0 and /usr/local/lib/qt3/libqt.so.3.0. This is how it's supposed to work for us... We don't need more version numbers to develop with the right stuff. And we don't use sonames too much, even though yes, we support them. Having everything visible upfront in the library names is simpler for us. We have also had a few cases where we want to have control on the major version number: changes in system libraries, the C or the C++ library, for instance, mean that the major number of a few libraries also need to change, because some include file or another was changed. The current automake/libtool mechanism is just fine for this, since we just need to override one variable from the command line. In reality, our biggest (read: very large) peeve with libtool is that it parses too much of gcc internals, and too little at the same time. I'm very annoyed at libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la expanding into some stuff like: cc -L/usr/local/lib -L. -o foo foo.o -lbar which gets us the libbar installed under /usr/local/lib instead of the one we just built...
