[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ABI-compatability (was: Re: New control field proposal which could help on gcc3.2 transition)



On Thu, Sep 12, 2002 at 10:25:39AM -0400, Ben Collins wrote:
> Now, if libfoo 1.1.1 compiled packages break because libfoo 1.1.2 is
> compiled with gcc-3.2 (which I assume only happens with c++, not just
> C...), then we need a more specific mechanism.
> 
> The problem with your solution is that no package knows when it is
> changing over to gcc-3.2. This occurs on a per arch basis, and not
> always the same changes. For example, hppa is already at gcc-3.0, and
> ia64 has been using a gcc-2.96 variant (gnu-pro or something).
> 
> Packages cannot decide when they need to do this. So we need a different
> solution to your example.

So to put it clearly:


1) the soname has to be changed when the ABI changes

2) g++ (or linked in shared library) changes the ABI, therefore
   triggering a change in the soname

3) 2) depends on the distribution and the architecture

4) Because of 3), 2) cannot be clamped by the upstream[1]


Adding this up, we can conclude, that the soname has to be a function of
the libraries own ABI version, the compilers generated ABI version and all
shared libraries the library links to. AND while the libraries own ABI
version can be set by upstream at design (or programming) time, the
complete soname can only be computed at build time, incorporating the
used compiler and libraries. 



I hope this recapitulation doesn't oversimplify.





Regards, David

[1] Which is good, see gcc-3.0 on hppa.

-- 
Afrika kommt nach Europa. Das ist der Kontinentaldrift. Da kann man auch
mit einem neuen Asylgesetz nichts dagegen machen. Das sollte mal wer
denen von der FPÖ erklären!
	-- Dieter Nuhr (www.nuhr.de) in der Wiener Remise, 2002-08-02

Attachment: pgpO7Yxsh1EW9.pgp
Description: PGP signature


Reply to: