Re: Plans for ABI migration

[Bernardo Innocenti <bernie at codewiz dot org>]

On Wednesday 10 January 2001 03:16, Marc Espie wrote:

 > >did the steering comitee already set a roadmap to ease the
 > >migration from the old C++ ABI (gcc 2.9x) to the new one
 > >(gcc 3.x)?
 > >
 > > This is expecially needed for systems using gcc as their
 > >official C++ compiler, such as Linux and *BSD.
 >
 > This is a weird message, you start off sounding like you
 > want to ask for general questions, then all the rest of
 > your post is completely linux and glibc-centric.

 Indeed! I didn't notice the way I slided on Linux-only
discussion when I wrote it... It really sounds like I don't
know/care about the others, which is not the case.


 > As far as OpenBSD goes, things are rather simple: we'll
 > test gcc 3.0 as it comes near completion. If it works,
 > we'll adopt it (and we'll complain loudly if the pre-versions
 > don't work... well, I hope not, but in reality, I think we won't
 > be able to switch until gcc 3.0.1 or gcc 3.0.2).

 Perhaps a reasonable compromise could be keeping the old
gcc for the kernel (and perhaps the userland too) and
adopting gcc 3.0 as the default compiler for building packages.

 The faster we can forget of gcc 2.x, the better! Today's C++
applications for UNIX must employ all kinds of ugly workarounds
to trick gcc into compiling valid ANSI C++ code. I guess it's
very frustrating for C++ developers and it prevents them from
taking advantage of the most advanced C++ features.

 There will be a (hopefully short) transition time when C++
projects such as KDE will have to support both gcc 2.x and 3.x
until all OSes have upgraded to use 3.x by default.


 > As far as the C++ API goes, things are simple: nothing that
 > was built before will have a chance to work with the new API.
 > Put simply, this means major version number changes for EVERY
 > C++ library in the system...

 This is not a problem for Net/OpenBSD, because you have full
control over the source base. But Linux is made up of hundereds
of packages coming from different places. Distributions willing
to upgrade to 3.x before it becomes widely available will
probably have to applay lots of custom patches to C++ code.
Each one will do it in a slightly different way. Imagine the mess!


 > Considering that there aren't that many C++ libraries around,
 > this shouldn't be hard.  It is just a question of providing the
 > newer C++ libraries along with the newer system.

 Well, C++ is not yet the main programming language on UNIX,
expecially for historic subsystems of *BSD and Linux, but it
has become quite popular in the last few years for GUI applications.

 Users with a full-blown OpenBSD desktop will still suffer when
upgrading their system, unless they installed everything from
packages AND all those packages become immediately available for
the new release.


 > As compared to other systems, there are merits to having development
 > proceed at a safe pace, with releases every six months. Our releases
 > are perceived as dependable, and people don't shirk the update, as,
 > say, in some other world, where no-one updates to version 11.0,
 > everyone's waiting for 11.1 which is said to be less buggy and
 > actually work.

 Yes, the BSD people have always been known to do things right
the first time.

 EXECPT for that kcore crap!! :-)


 > Also note that everything that happens outside of those six months is
 > developer's issue: the intermediate steps might not be smooth, but we
 > don't really have to care. Those people who go through intermediate
 > snapshots are not ordinary users.  They take the risk, they can live
 > with it.

 I've been tracking NetBSD-current for a long time. I don't mind
if something screwes up from time to time. I like living on the
bleeding edge. But this time it's going to be a major hassle even
for developers. Recompiling megabytes of C++ code before you can
run your desktop again is quite frustrating. Expecially when most
of that code has not yet been fixed to work with the new gcc release
so you must babysit the build to fix small problems every 5 minutes.


 > Personally, finally having a somewhat dependable C++ API, and a decent
 > library, is something I can't wait to have. This has been one of the
 > major shortcomings of C++ (practically) that I've seen people oppose
 > me with, so gcc 3.0 is definitely a good thing. I believe that we will
 > have to start worrying about C++ updates *after* 3.0, if for whatever
 > reason it doesn't deliver on the stable ABI plan.

 I do agree. I'd never juggest crippling the ABI or delaying the
release in the name of backwards compatibility.

 I just recommend some simple trick with the dynamic linker to
allow the users to keep two sets of C++ libraries. On Linux, it
has been done when the OS was migrating from libc5 to glibc.
It has been a pain anyway, but at least you could still run your
old programs if you had the old libs.

 If it has been possible when replacing libc with a totally
different implementation, my guess is that it's also possible
when the C++ ABI changes.

-- 
  // Bernardo Innocenti
\X/  http://www.codewiz.org