On Fri, Oct 24, 2008 at 12:30:00PM -0400, Stefan Teleman wrote: > >You can always say that the link in /bin points to the latest version > >and so is Volatile or Uncommitted, or you can say it's Committed and > >commit to carrying that version as the default for a long time. > > Unfortunately, this discussion is, again, C-centric. > > Yes, for C programs, it most likely does not matter that we will rev up the > GCC symlinks in /usr/bin -- GCC's C ABI is stable. > > That is not the case for C++. GCC's C++ ABI is not stable, and it changes > in an incompatible way, even between Minor Releases.
I understand that. This is why we have an interface stability taxonomy. We decide what stability attribute we want to give to the G++ ABI, label all the relevant interfaces accordingly, deliver them, and move on. > [...] > > The GCC C++ ABI has changed in an incompatible way between GCC 4.3.2 and > GCC 4.4.3. Unknown to the developer, we have changed the symlinks in a > patch, and they now point to GCC 4.4.3 instead of the previous GCC 4.3.2. The developer will either know because we've told him in the docs, or this won't happen because the stability attribute that we decide to apply to G++ is such that we cannot change the default version in a minor release. Note that the G++ ABI stability issue is a bigger issue that needs to be addressed. Options: 1) Don't deliver G++; tell developers that the C++ ABI for Solaris is the Sun Studio C++ ABI. 2) Deliver G++ and declare it Volatile; tell developers that we may change the default G++ version delivered at any patch/update/ OpenSolaris release, and let them deal with the headaches. 3) Deliver G++ and declare it Committed; tell developers what to do in order to use the latest G++ instead of the default G++, and let them deal with the headaches. 4) Deliver G++ but not in /bin; tell developers how to find it and to pick the version they want, and let them deal with the headaches. 5) Deliver G++ and declare it Committed and commit to work with the GCC community to make its G++ ABI truly stable. 6) Something else?? (1), (5) and (6) are probably not realistic. So choose from (2), (3) or (4), propose it, and if the ARC approves it, your choice becomes our policy, else we'll eventually end up with one of the other two options. Nico --
