Steve Langasek <[EMAIL PROTECTED]> 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
