[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: first impressions of Red Hat 8.0



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?

> 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.)

> 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/

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.

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.

> 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.

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

> 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?

Steve
-- 
steve@silug.org           | Southern Illinois Linux Users Group
(618)398-7360             | See web site for meeting details.
Steven Pritchard          | http://www.silug.org/

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