[Rearranging] > 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.
On the other hand, I've spent time thinking about all of these already. For instance, let me point one thing out that you mention a couple of times but don't give enough attention to: > just how hard it can be to fix such bugs. We've had similar problems > with the shared libgcc. We've fixed a lot of these problems already; I will be brave and say that we have fixed most of them. On Mon, May 23, 2005 at 11:04:14PM -0700, Zack Weinberg wrote: > 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. As Paolo wrote, it will soon. This isn't the only thing it'll fix. For instance it would let us use bool in those interfaces again, without breaking Darwin. > 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. With top level bootstrap this is trivial to get right. The top level should set the library path appropriately for the stage. > 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. You do realize that libgcc is "compatible" in the same way as glibc, right? If you do this and don't copy the hypothetical gcc 4.3 libgcc_s.so.1 into your system library directory, C++ stands a decent chance of not working. Not a new problem. I don't know why you think that the DT_RPATH would cause the build to fail. A DT_RPATH pointing at a non-existant directory is harmless and LD_LIBRARY_PATH will still be used. It's only if you had an old copy in $prefix that DT_RPATH would bite you. And there are plenty of other ways around this - for instance, a shell script named xgcc in the build tree which LD_PRELOADs the correct copy using a full path. > 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. You mean, like GCC 3.4 and GCC 4.0? -- Daniel Jacobowitz CodeSourcery, LLC
