On Fri, Jun 29, 2001 at 01:27:21PM +0200, Robert Bihlmeyer wrote: > Would you think it a good strategy for an xmlrpc-c application to link > statically with its own version of your library, because there are > set-ups out there which have a too old, too new, too screwed > installation of xmlrpc-c?
Ah! But I've been extremely careful with my ABIs, so there *aren't* any broken versions (yet). ;-) If I remove my library's internal, private copy of expat, I will actually be *creating* the first known "broken" version of xmlrpc-c on any known Linux distribution (where "broken" is defined as having the same soname but a different ABI). > I'd rather have users yell at the distros that ship a broken expat than > having Debian users pay the price for that. Expat 1.x was never packaged as a shared library by its upstream maintainer. Therefore, any version I might find has a soname assigned by a downstream maintainer on some distro. Since there's no standard, everybody's right. And everybody's wrong. :-( There's nobody for the users to appeal to in this matter. Basically, expat 1.x was designed to be used exactly as I'm using it--as an internal library. I actually disagree with this decision, but my life is much easier if I respect it. > No argument here. I assume that this requirement will be dropped/modified > somewhen in the future, once you consider 1.95 (or 2.0, or whatever) > suitable. Possibly. I know, from personal experience, that James Clark typically produces highly correct code, and expat 1.x has been used in uncountable projects. A future decision to upgrade to expat 2.0 would need to involve a thorough audit of the new code base, since it's maintained by a new author, and used less extensively throughout industry. I will make this decision when--and if--I'm comfortable with it. > On a releated note, the security process also becomes more sluggish > and dependent on more people. Now two persons (James and you) must fix > their copies of expat to remove a vulnerability. Yes. This is unfortunate. But at least expat 1.x is extremely stable software, and the expected number of security updates is very small. > > A) Make xmlrpc-c use the Debian version of expat. This would violate > > constraints (1), (2) and (3). > > Nope. IIRC the older expat is in Debian in the package libxmltok1. > Relying on that would satisfy (3) and (1). Probably not (2) because > one can always find a platform where a library is not installed. No, it still breaks constraint (1)--preserving the ABI/soname relationship across multiple distros. Since the upstream version of expat 1.x has no sonames, I simply cannot rely on every distribution chosing a consistent soname for it. Hence, if I want any degree of portability, I must create my own sonames for expat 1.x and make them part of xmlrpc-c's ABI. (Theoretically, it might be possible to create new sonames without duplicating the actual library code, but I have no reason to believe that ldconfig is willing to jump through such hoops on my behalf.) > > All things considered, my preference (as the upstream maintainer) leans > > strongly toward (C). > > That's a good measure, although I'd obviously prefer (A). If (A) were at all feasible, I'd prefer it, too. But James Clark never packaged expat 1.x as a shared library, so the downstream inconsistencies in various distros are a bit overwhelming from my perspective. Once the new version of expat stabilizes, this problem may go away--*if* the new maintainer scrupulously follows the rules for updating sonames.[1] And if there's actually a consistent ABI for expat 2.x, then I can rely upon it to produce a consistent ABI for xmlrpc-c. It's simply that--in my opinion as the upstream author of xmlrpc-c--this day has not yet arrived. Cheers, Eric [1] For those of you following this discussion, you can find a good summary of these rules under the info topic (libtool)Versioning. Libraries which fail to obey these rules cause really ugly problems, like RedHat's libjpeg fiasco a few years ago.
