Re: first impressions of Red Hat 8.0

[Jeff Licquia <jeff@licquia.org>]

On Mon, 2002-09-30 at 16:07, Steven Pritchard wrote:
> On Mon, Sep 30, 2002 at 03:40:46PM -0500, Jeff Licquia wrote:
> > Word on the street is that gcc 3.2's ABI is "it", which means that it
> > should be compatible with future gcc releases, Intel's compilers, etc. 
> > So, everyone out there will be migrating to 3.2 at some point.  This
> > part is good.
> 
> Not only that, but supposedly gcc 3.x is the most standards-compliant
> C++ compiler out there.  This has to be a good thing, right?

Oh, yeah.  Don't get me wrong; gcc 3.2 isn't the problem here.  It's the
solution to a whole host of other problems.

> > The question everyone's asking, though, is this: what to do with
> > existing libraries?  If you mix C++ apps compiled with gcc 3.2 with C++
> > dynamic libraries compiled with gcc 2.96 (or vice versa), the results
> > will be... interesting. :-)
> 
> While this does suck, I would like to think that everyone made this
> point well enough when Red Hat moved to gcc 2.96 for people to be
> prepared for it now.  As other people pointed out, the pain was going
> to be there when gcc 3.x came regardless of what version of gcc
> everyone was using up to that point.  (Even the last couple of stable
> versions of gcc didn't keep a stable C++ ABI.)

True.  This was why, for example, Debian woody shipped with gcc 2.95 on
most architectures.

> > Remember that KDE, as an example, is almost entirely C++; ask yourself
> > how many freshrpms KDE apps you've installed, and whether you'd like
> > them to all go away now.
> 
> Not an issue with open source...
> 
>     http://psyche.freshrpms.net/

True.

That's an interesting site.  They have an autobuilder for RPMs?  Do you
happen to know if their autobuilder is open source?

> Oh, and totally off the subject, but I thought you might appreciate
> this, Jeff...  This is in the changelog for the freshrpms apt package:
> 
>     * Thu Jul 11 2002 Matthias Saou <matthias.saou at est.une.marmotte.net>
>  
>     - Removed the mirror patch that was preventing signed repositories
>       from working.
> 
> He also seems to have updated to apt 0.5.x.

/me needs to check into that.  It would be nice if someone had
forward-ported apt-rpm...

You did know that apt is written in C++, right?  :-)

> Back to the subject at hand...  I really only see this as an issue
> with non-free software, and anyone distributing non-free software
> should have listened a long time ago and just linked libstdc++ and
> any other C++ libraries statically to their applications.

There are lots of good reasons why static linking is bad.  Whether it's
worse than the compatibility issues is an open question.

I don't think too many proprietary vendors have committed to C++ to a
great degree yet.  (theKompany seems to be a lone exception, given their
focus on KDE.)  Those that have, I imagine, are in the "certify the
platform" camp, use rpath and ship their own libs, or statically link.  

Anyone know if Loki used C++ in any of their stuff?  I'm sure I'll care
in the very near future.

> > Now, the standard solution to this is to increment the soname - that's
> > the first number after the ".so" in the shared library name, so
> > libc.so.6's soname is 6.  That indicates binary-incompatible changes,
> > and is the secret to why Linux doesn't suffer from "DLL hell" like
> > Windows does.  Unfortunately, not many C++ library developers are taking
> > to this, so the standard solution seems to be to just rebuild everything
> > with the new compiler and tell the poor sap with older C++ apps "too
> > bad, upgrade or die".  (In other words - DLL hell.)
> 
> If anything, I'd think this would be a big strike against trying to
> use C++ for anything serious.  Not only do you then have to worry
> about the OS ABI, but also the C++ ABI, which is (or was) bound to
> fluctuate, given that the C++ standard is quite new.

Unfortunately, we have users, and (some) users write in C++.

Also, not all OSes have had such problems.  Windows developers don't
seem to have any more problems than "DLL hell" normally gives them. 
(Maybe they're so used to "DLL hell" that they wouldn't recognize this
problem if they had it.)

> Then again, one might see this as a good reason for LSB.

The LSB has refused to have a C++ section because of this problem;
hopefully, once everything calms down, they will.

> > Debian is already seeing problems like this.  We were hoping to be able
> > to make it possible for old C++ apps to run properly and still be
> > binary-compatible with cutting-edge distros like RH, but that may not be
> > possible anymore.
> 
> I hate to sound like I'm bashing Debian here, but I have to say it... 
> If Debian updated the entire system more than once every couple of
> years or so, wouldn't this be a lot less of an issue?

That's a problem for sure, but it's not this problem.

We just released woody two months ago.  By the time we release sarge,
whether that's six months or two years from now, we'll likely be based
on gcc 3.2.  In the meantime, people will be using woody to do useful
things (we hope), like develop and deploy software written in C++.  What
will happen to those people when they upgrade to sarge after it's
released?  Will their deployed software suddenly break?

Debian's compiler people were working on some ideas and trying to get
some consensus on getting everyone to up their sonames for gcc 3.2. 
That way, people wouldn't need to recompile their apps to upgrade; the
old sonamed libs would remain on the system for the benefit of such old
apps.  Unfortunately, it turned out that RH had already decided to "be
first", and hadn't thought through these things in their rush to
judgment, so getting everyone to increment the soname would have made a
bad situation even worse.

(I should point out here that I've heard a lot of this third-hand.  If
someone were to prove me wrong, say by showing that RH 8 has all of KDE
linked against libqt.so.4, then I'd be happy to eat my words.)

Debian also considers it important to follow the community in ABI
standards; we care if our C++ ABI is incompatible with
RH/SuSE/Mandrake/whoever.  Further, the LSB is likely to start mandating
C++ ABIs once gcc 3.2 is widely deployed, and I guarantee you that they
will likely follow RH's lead rather than "strike a blow for
correctness".

It's not like there aren't solutions.  We may have to tell people
"rebuild all your C++ code" or something like that; we may do something
like we did for the a.out -> ELF migration.  But we don't like to do
that, and we think it all could have been avoided.  It's hard to make
claims about Windows DLL issues, for example, when we create the same
problems for ourselves for no good reason at all.

I don't think I have a real point, other than whining about RH's
propensity to rush into things without thinking.


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.