> I was thinking about the same thing the other day and was reading the > libtool manual[1] but came to the conclusion that the versioning system > provided by libtool's -version-info is incompatible with the versioning > system used in Xerces-C++.
Xerces is improperly using the filename to signal the version. That's what you do when you're not using a versioning system. It works (and is in fact the best thing to do on Windows), but it's non-standard for Unix. > For example, the last component in --version- > info is the so-called age: "The difference between the newest and oldest > interfaces that this library implements." while in Xerces-C++ it is a > binary-compatible bug-fix release number. It's not a good idea to tie the library name to a package release. > Also the instructions guidelines > provided in the libtool manual (section 7.3) about when to update each > component seem to contradict those of Xerces-C++. Unless we do something > like this: > > -version-info 3:0.0:0 I don't really understand the issue there, but whatever Xerces is doing now is wrong. It's very important that the .so files be laid out properly so that RPM packages will co-exist properly, and runtime linking will point at the latest "compatible" library installed. Far too many open source projects are refusing to do this properly. OpenSSL is a prime (and truly hideous) example. > Plus I am very sceptical about relying on any additional functionality > in libtool since, in my experience, that thing is ridden with bugs. If > anybody has any comments on this, please share. It's a libtool option to get the linker to produce the right filenames, but that's about it. It's not a libtool feature per se, and it works just fine. When you change your code, you update your makefile as needed. I've never had any trouble with that option. -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
