Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, May 23, 2005 at 09:01:20PM -0700, Zack Weinberg wrote: >> Furthermore, as I've said before, I support migrating >> to C++ -- but only if the C++ ABI and libstdc++ soname are first >> permanently frozen. If we do not do that first, we risk being trapped >> into a situation where we need specific versions of GCC to compile >> specific newer versions of GCC, which would be a Bad Thing. > > You keep saying this and I don't think it means what you think it > means... > > Being stuck requiring a specific version of GCC to compile a specific > newer version of GCC would be a restriction on _source compatibility_ > and has nothing to do with binary compatibility. I don't see any way > that the libstdc++ soname, for instance, could matter to this at all. > > If you do, then please be more precise about what problems you're > talking about.
Um, yeah. I completely botched that explanation. My apologies. I'm concerned about four different scenarios which may arise when the preexisting C++ compiler and runtime are ABI-incompatible with the C++ compiler and runtime being built; none are source compatibility issues, as you point out, however two of them have just the same effect from the user's point of view: imposing constraints on what compiler can be used to build the compiler. Scenario one: Suppose that both libcpp and gcc start using <vector>, and that the initial compiler/runtime's implementation of <vector> is binary incompatible with the implementation being built. Libcpp is currently built only with the initial compiler. Bootstrap will fail in stage 2, when we try to link libcpp modules expecting the older <vector> against a library implementing the newer <vector> (or perhaps the link will succeed but the resulting executable won't work). This scenario, at least theoretically, becomes a non-issue if we make top-level bootstrap the only option before we start using C++ features in GCC, but that hasn't happened yet. Scenario two: Suppose that we have not found every last place where LD_LIBRARY_PATH, or equivalent, needs to be set during bootstrap to ensure that the dynamic linker binds the stage 2 compiler to the shared libstdc++ that it's expecting. If there isn't a libstdc++.so in /usr/lib, or if there is but it is not compatible with the one the compiler wants, again bootstrap will fail. Any time this scenario comes up, it is attributable to a bug in the Makefiles, but you know just how hard it can be to fix such bugs. We've had similar problems with the shared libgcc. Scenario three: Suppose that libstdc++.so.7 (gcc-4.2) and libstdc++.so.7 (gcc-4.3) are compatible in the same way that libc.so.6 (glibc-2.0) and libc.so.6 (glibc-2.1) are compatible: that is, if you build a binary against the first, it'll run against the second, but not vice versa. Now, suppose that on some system gcc-4.2 is /usr/bin/gcc, its libstdc++.so.7 is installed in /usr/lib, and we're trying to use it to compile gcc-4.3, to be installed in /opt/gcc-4.3 or some other weird place that is not in the dynamic linker's default search path. Furthermore, scenarios one and two have been properly avoided. The bootstrap process will produce final compiler binaries that have been linked against the 4.3 libstdc++.so. If we include RPATHs in those binaries, bootstrap will fail, because the library isn't installed yet; if we don't, bootstrap and testing will succeed, but the installed compiler will not run unless the user knows to set LD_LIBRARY_PATH, which has its own problems. DT_RUNPATH could theoretically be used to make this work, but we can't count on DT_RUNPATH. If I were evil, I might point out that this is exactly the same problem that various people were complaining about last week, of depending on newer libraries than one expected to. Scenario four: Suppose that we manage to avoid all the above scenarios. Suppose further that we think we have achieved binary compatibility between different versions of libstdc++, but we are wrong. Then 'make install' is likely to overwrite the libstdc++.so on the system with one that is, in fact, not compatible, and break already-installed software. This could, of course, happen even if we don't start using C++ in GCC itself - I bring it up to caution us against rushing into declaring libstdc++ ABI-frozen. I'd want to see at least two major releases with no libstdc++ soname bump and no problems reported, before I had confidence we'd gotten it right. I want to emphasize that I don't think any of these are unsolvable problems. I do think they are all real problems, and I think there are going to be other problems I haven't listed above, and I want to be sure we have considered the problems and have solutions in hand before we take the plunge. > There is no such thing as an ABI that will never again be changed. > Designing anything at all around that assumption is just asking to > be hurt. C++ ABI stability (including libstdc++ interface) on a par with the C ABI (including libc interface) would suffice. zw
