Nicolas Williams wrote:
> On Fri, Oct 24, 2008 at 12:01:52PM -0400, Stefan Teleman wrote:
>> The other problem with having symlinks in /usr/bin is that we implicitly
>> assert a preference for one version of binutils, or GCC, over another.
>> Meaning: as long as there is only one version of binutils, or GCC,
>> available, everything is fine: the symlinks in /usr/bin point to the sole
>> instance. This no longer holds when there is more than one version of
>> either component available: we are making an implicit value judgement ("the
>> latest version is the one we like best"). This can create binary
>> compatibility problems.
>
> Lots of things in /bin are "versioned" in some way. That's not a good
> reason to keep them out of /bin -- users still need them, and we're not
> going to tell them to muck with PATH to get them.
>
> We've been down this road and the ARC long ago decided to put all this
> stuff in /bin, versioned or not.
>
> 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.
Consider the following scenario:
Time T0:
--------
/usr/bin/g++ -> /usr/gnu/gcc4/4.3.2/bin/g++
/usr/bin/c++ -> /usr/gnu/gcc4/4.3.2/bin/c++
This is GCC version 4.3.2 with its associated GNU Standard C++ Library, and its
own C++ ABI.
Time T + N:
-----------
/usr/bin/g++ -> /usr/gnu/gcc4/4.4.3/g++
/usr/bin/c++ -> /usr/gnu/gcc4/4.4.3/c++
This is GCC version 4.4.3 with its associated GNU Standard C++ Library, and its
own C++ ABI.'
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. This developer
now wants to build a new C++ software component with our default g++, based on
the symlinks in /usr/bin. This new C++ software component depends on some other
C++ libraries, which have already been built with the previous version of GCC,
and are already installed on his/her system.
Result: different and incompatible C++ ABI's will be combined within the same
executable address space.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman at Sun.COM
