Again, a port update of a library has bumped a .so version [in this case libatk-1.0.so.200 -> libatk-1.0.so.400]. This leaves a bunch of binaries linked to the old .so which won't start.
Other recent examples include libxmms.so and libintl.so. Is there an elegant and quick way to relink a given binary to a different version of a particular .so, eg. "mvld foo foo.so.1 foo.so.2"? I'm aware that rebuilding is the right thing to do since stuff can change in the libs, however experience from symlinking .so.N to .so.N-n shows that this almost never results in problems. For the record, I'm largely clueless about the details of linking, but I also wondered why we have all the .so -> .so.N symlinks if the linking as always to the .so.N. Is the fact that some libs don't follow the major/minor rules[1] a/the problem? I've read ld(1), ldconfig(8) [-r shows the .so.N hints], rtld(1) and other pages, googled a bit and am only slightly wiser, but not enough to answer my own questions. Your clues will be gratefully received. [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/policies-shlib.html -Andrew- -- _______________________________________________________________________ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 | _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
