Re: GCC 3.2 transition
Steve Langasek <vorlon@netexpress.net> writes:
> I sincerely hope that g++ 3.2 applications will be allowed to coexist on
> the system with g++ 2.95.x applications.
I don't think this will happen, atleast not for shared libraries. Any
scheme that tries to solve this problem will be horribly complex,
require manual interaction with the build process, and produce
binaries that are incompatible with anybody else's binaries.
> And really, there is no reason to not allow this: because of the
> nature of the ABI breakage, you will never be able to accidentally
> mix-and-match g++ 3.2 binaries with g++ 2.95.x binaries, because
> they will not be able to resolve each other's symbols at the linker
> level.
Indeed. So there is no accidental linkage of the wrong library. If
something breaks, it will be visible right when it starts, and the
solution is clear: recompile the package that uses the old ABI.
> It is precisely because the symbol name mangling has changed with
> each revision of gcc that we need to worry about this transition in
> the first place.
The ABI deals with way more aspects than name mangling, but - yes.
> If other distributions are planning to move from 2.95.x to 3.2 without
> changing sonames, then we need to start talking to them /now/, and make
> sure we aren't all stuck with this terrible mistake.
It is not a terrible mistake, it is the only solution that can work at
all. *If* sonames are changed, we will get a terrible mess. If we use
the sonames defined by the upstream maintainers, everything will work
out nicely, as everybody uses the same sonames for the same libraries.
Other distributions *will* build the packages from source as-is, and
thus *will not* change the sonames of the library: they can rebuild
the entire distribution from source, so there simply is no need to
keep the old shared libraries.
Regards,
Martin
Reply to: