Re: gcc 3.2 transition in unstable
"H. S. Teoh" <hsteoh@quickfur.ath.cx> writes:
> Richard Kettlewell wrote:
>> 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.
Please don't write any libraries, then.
> I can't decide upon the ABI, since that depends on the compiler (as
> we've seen in this gcc transition).
You _can_ include the compiler part of the ABI, it's just inconvenient
with current tools, and nobody's had to do it before for Debian
because there's only ever been a single compiler ABI.
Slightly disappointingly things like the Libtool manual don't even
mantion the problem. This increases my suspicion that the right place
to fix this would have been in GCC itself.
> 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.
Multiple APIs could compile into a single ABI, too. But for the
purposes of the soname the ABI is all that matters.
> 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).
I believe I already suggested this, only without the misconception as
to the difference between API and ABI:
| A further, probably better, 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.
--
http://www.greenend.org.uk/rjk/
Reply to: