On Wed, Jan 08, 2003 at 05:26:47PM +0000, Richard Kettlewell wrote: [snip] > > Why don't we just change the sonames? > > > > Because upstream chooses the soname to match their API. > > Sonames reflects ABIs, not APIs. If upstream fail to arrange for > different soname fields for different ABIs, wherever those ABIs come > from, then they have a bug. Umm... if I were an upstream author, I'd choose the soname based on the API. I can't decide upon the ABI, since that depends on the compiler (as we've seen in this gcc transition). OTOH, from the user's POV, the soname should reflect the ABI, since that's what he's linking against at runtime. So I posit that the soname actually encodes *both* the API and the ABI. Furthermore, because the same API can potentially compile into different ABI's (through using different (versions of) compilers), the soname must actually encode *two* variables. The API part is specified by upstream, and the ABI part is given by the compiler. > I agree that Debian should be extremely wary of unilaterally changing > sonames, of course. But the choice is not, or at least was not, > merely between "incompatible with latest Red Hat" and "incompatible > with old Debian"; another alternative is to persuade the relevant > upstreams to use proper sonames. Persuading upstream to use proper sonames doesn't solve the problem. Upstream *is* using the same API and hence, the same soname; it is the ABI that has changed in this transition. Like I said, upstream is responsible (and can be responsible only for) API changes. The ABI is something beyond upstream's control. > A further, probably etter, alternative would be for GCC to modify the > sonames of new-ABI libraries automatically. (Even better it would > include, possibly as as hash to keep things short, the sonames of all > the dependent libraries.) I believe this approach would minimize pain > for both library authors and integrators such as Debian. [snip] I think it is sufficient to extend sonames to have an API part and an ABI part as I propose above. Upstream supplies the API part, and gcc supplies the ABI part. This ensures that libraries can only be linked to API- *and* ABI- compatible dependents, without the need to encode all dependencies into a single soname (which would be rather ugly IMHO). This way, upstream doesn't have to worry at all about ABI changes; they continue working as before, bumping the (API part of the) soname when the API changes, and the compiler will suffix the ABI component to ensure that the resulting .so will never get linked into incompatible binaries. (Of course, for this to work across distros, it will have to be widely adopted. A good place to start might be to get the upstream GCC folks to actually implement this in a next release, or perhaps a testing release.) T -- "640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.
Attachment:
pgp2E7MXabB_1.pgp
Description: PGP signature