> bkoz pointed out that I forgot to update invoke.texi about > -fabi-version=6. Applying to trunk
I've been thinking about this. As it turns out, the mangling changes don't really impact the explicit instantiations compiled in to libstdc++.so. So, it seems possible to say 1. compile libstdc++.so with -fabi-version=6, and run the testsuites with the default abi (2) and have everything work. 2. compile libstdc++.so with the default abi and run the testsuites with -fabi-version=6. (Haven't tested this one completely yet.) Nothing tricky seems to be instantiated. That gives us a wider field of options for dealing with ABI issues... Here's my favorite idea at the moment for dealing with what we should be trying to encourage, ABI experimentation as part of GCC's mission for both technical excellence and liberty in computing. I think a compelling case could be made to ship 4.7 with a configure-time flag that sets the default C++ dialect to C++11. So, I would propose --with-std = dialect or --with-std-version=c dialect default, c++ dialect default be added to the top-level gcc configure and documented here: as: http://gcc.gnu.org/install/configure.html --with-std=dialect[,dialect] Specify a string that identifies the -std=dialect defaults for the built compiler and any associated runtimes. Default values are gnu99, g++98. For example, -std=gnu11,gnu++11 would build a compiler whose default language standards for "C" and C++ would be the GNU extensions to the C11 and C++11 standards. Then, I believe for C++ targets defaulting to C++11, then the language would be set to -fabi-version=6 and any other changes, and for the library, we'd use .so.7 and namespace versioning, and do the basic_string swap to __gnu_cxx::__versa_string (or alias it? hmm....) and any other changes. So. Why do it this way? Because I think this would be an easier way for maintainers and other interested parties to experiment with changes. If we are happy and things look promising, then these people can lobby the rest of the community (with their collected experimental evidence) to change the language defaults. Or not, since people will now be able to just set it themselves if they feel strongly about the issue. I suspect that the standard practice in the wider communities and/or sub-communities will become clear with a mechanism like this. At least, we'll have a better idea of which sub-communities care and which don't. That's still better than what we've got now... it's been a mighty long time to be at -fabi-version=2 and libstdc++.so.6...... Lemme know what you think. best, benjamin
