[svlug] Mandrake 8 beta thoughts

[Wayne Earl]

On Wed, 7 Mar 2001, Dagmar d'Surreal wrote:
> > What troubles have you seen with gcc-2.96?
> Some specific problems have to do with changes to the way symbols are
> stored and handles in libraries.  For example, if you have a static
> library that was built with 2.95.2 or egcs, or some other NON-EXPERIMENTAL
> NON-CVS version of gcc, and you attempt to link it into an application you
> compile with gcc-2.96, it will generall segfault and die the moment it
> makes the first call into that library, if it doesn't just explode into a
> bunch of pointy fragments during the linking (more common with shared
> libraries than static ones).  (And while some people will claim that these
> incidences are few and far between, I have already run into one case, and
> the point of having these libraries is so they can be changed without
> having to rebuild the entire system.)

Well yes, this could be a pain, but you would only run into this issue on
a Red Hat 7.0 system. All the RPMs on a 7.0 system are compiled using
gcc-2.96, so the only real way that I can think you would run into this
is:

1. Installing an RPM targeted at an earlier (RH 6.x or earlier) system,

2. Copying compiled libraries over from another system.

3. Propriatary (closed sourced) library or binary.

#2 is poor system management, and #1 is easily solvable. Either grab a
SRPM and recompile, or compile from source. With #3, you can't upgrade
anyways.

> 
> Furthermore the gcc team even went so far as to say that there was a good
> chance that the way symbols are handled might be changed *again* in a
> manner that would introduce binary incompatibilites with 2.96 so that
> expecting the rest of the world will eventually "catch up" to RedHat's
> compiler was a seriously flawed assumption.
> 

But this would ALSO make 2.94 binaries incompatable, so you would be no
better off sticking with 2.95.

> If they'd had any sense, they would have simply waited for 2.95.3 to be
> released.  The Debian people don't seem to have a problem with waiting for
> it, and I'm guessing that Volkerding doesn't have much of a problem with
> waiting for it either, since the 2.95.3 version is currently in
> slackware_current, which is known to be quite volatile and subject to
> change at any time.

Red Hat stated that they did this because of internationalization concerns
and issues with non-x86 systems. (Although I have no first hand
experience with this, I am told by friends who do serious C coding that
gcc is the absolute WORST compiler to use on a non-x86 
platform. YMMV). IMO, these are reasonable technical reasons. See:

http://www.freeos.com/articles/2801/2/11/

> It's just a matter of being patient... which isn't exactly a familiar
> concept to people who primarily focus on meeting short-term revenue
> expectations to keep stockholders happy.
> 

Interesting (and wrong) assessment. Speaking of short-term revenue
expectations, can anyone here name the first compiler to be 100% compliant
with the ISO C++ standard? (You're not going to like the answer.) Can
anyone here tell me why gcc STILL isn't ISO C++ complient, with the
standard being about 3 years old?

Sometimes, if you have too much patience, the world will pass you by.

-- 
Wayne Earl
wayne at qconcepts.net
http://www.qconcepts.net
gpg key fingerprint: 2B98 4A92 2C4A 9BD9 81B3 6534 01BE 1302 B52C 40BE