Re: first impressions of Red Hat 8.0

[frog@intertek.net]

I'm not a power user but I avoid Microsoft whenever I can and I've
always just liked SuSE for some reason. Does the compiler issue affect
my system, I like rocksanddiamonds  and descent but prefer the gnu C++
compilers to visual C++ (I'm a student) because I'm not paying for
anything Microsoft does that isn't the best and or is worth the money.
They are good at some things and I'll support that.



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

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