Marc Espie <espie <at> nerim.net> writes: > > 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.
I have a hard time to learn this from the manpages, by the way. > - 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. I may need more information in order to be able to fix the bug you describe later. Could you just point me to the CVS files that implement the ld and the ld.so search algorithms? Thanks. > 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... Ah, ok. > 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. Again, to work on Keith's proposal for OpenBSD, I'd need more information here. > Having everything visible upfront in the library names is simpler for us. Sure. > 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. Sure. > The current automake/libtool mechanism is just fine for this, since we just > need to override one variable from the command line. OK > 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 assume this (above) is not about quite the same bug as this below(?): > 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... Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption about which path overrides which. Current branch-1-5 does not do this on GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD. For static libbar, it creates on both systems gcc -o foo foo.o ./.libs/libbar.a and for shared libbar it creates gcc -o .libs/foo foo.o ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst In both cases executing ./foo picks up the new library. There was a bugfix after 1.5.20 which before caused the shell wrapper (in the shared case) to miss setting all environment variables correctly, so really the CVS version may be needed. We hope to have an 1.5.22 release very very soon. If you still get this bug, and it is not exposed by the libtool testsuite, please let me know. Writing a test for it is pretty trivial (in fact I can provide the one I just used to provide this very answer). If you can provide more information (see above) or even a login where I can test, I should be able to fix this myself, given some spare time. Cheers, Ralf
