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

Re: first impressions of Red Hat 8.0




that was cool





Jeff Licquia wrote:
> 
> On Mon, 2002-09-30 at 09:14, Steven Pritchard wrote:
> > And now the good stuff...
> >
> >     * gcc has been updated to 3.2, which is almost certainly a good
> >       thing (although it might be a while before you can compile a
> >       stock kernel with it).
> 
> I'm not so optimistic.
> 
> The C++ application binary interface (ABI) has been in a state of flux
> for a while now, to the point that you've really needed to be careful
> when compiling and linking C++ code.  When you hear complaints about
> "Red Hat's buggy prerelease compiler and incompatibility with the rest
> of the world", this is the problem you're hearing about.
> 
> 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.
> 
> 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. :-)  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.
> 
> 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.)
> 
> This also means that cross-distribution compatibility will suffer,
> especially in environments like KDE which depend so closely on C++.
> 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.
> 
> Sorry about being such a sourpuss. :-)
> 
> -
> 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.