On Tue, 2005-05-24 at 19:17 -0400, Daniel Jacobowitz wrote: > On Tue, May 24, 2005 at 04:20:27PM -0700, Zack Weinberg wrote: > > Um, there have been plenty of cases in the past where the top level set > > something correctly and the subdirectory makefiles overrode it with an > > incorrect setting. > > Ah, but once we have a globally correct setting in the top level we can > brutally eliminate settings further down. This does require toplevel > bootstrap.
Can, yeah, but how long will it take to get done? It's two years later and we're still ripping 2.13isms out of gcc/configure.ac at a painfully slow rate. > $ORIGIN is nifty; but do you know how portable it is? I've got no > clue. Linux and Solaris, is all I know. Note that the solution needn't be the same on all platforms. > > If GCC 4.1 comes out without anyone having reported 3.4/4.0 > > incompatibilities, and continues to provide libstdc++.so.6, then yes, > > that would be like what I mean. However, the active development on the > > libstdc++.so.7 branch means that we haven't even started the clock > > running on this criterion yet. > > That would be three major releases unless you're counting differently > than I am. My point was that we did preserve the soname between 3.4 > and 4.0, and no one's reported trouble because of that yet - and I have > fairly high confidence that no one will. I'm counting two full development cycles since the initial release with the frozen ABI. Or, perhaps it will make more sense if I describe it as one full development cycle since the release of the second compiler that implements the frozen ABI. This is to give people time to find and report problems, which they are more likely to do when it involves comparing two official releases than when it involves comparing a released version to the development trunk. 4.0 has only been out for what, a month now? And people are being skittish about adopting it because of all the optimizer changes. zw
