[lug] Something tweaked in RH 7.1 g++?

[D. Stimits]

"Scott A. Herod" wrote:
> 
> Hi Keith,
> 
>   I can't comment on Dan's response.  However, I have had problems
> running code that was compiled with gcc 2.96 that was also linked with
> code compiled with 2.95 or 2.91.  I've not dug for details but most
> often have problems when trying to do dynamic_casts of classes that
> contain STL data types.  The typical error is a segfault somewhere deep
> in the dynamic_cast code.  It works when I restrict to one compiler. The
> problem can still occur even when everything is compilied -g -O.

Yes, I forgot about this one. Mixing compiled libs from one compiler and
another will fail...the object file format changed in some way between
code prior to 2.96, 2.96, and later than 2.96. Make clean can sometimes
get rid of stale object files, and miraculously cure such a problem,
depending on how the project is set up.

> 
>   I only understand the details of how the compiler works enough to make
> dangerous speculations but since I believe that the vtable layout
> changed between 2.91 and 2.96, I wonder how how a dynamic_cast can work
> at all.

This is probably correct. dynamic_cast would require the "shape" of the
object layout to be the same between compilers, else it'd use the wrong
offset.

Combining this with a reply to another email (saving space), quoting:
<quote>
If, as D. Stimits says (and I believe him and you guys over my texts at
this
point), the compiler in 7.1 is better (excpet as noted by D., I can call
you
D., right? :) ), why did Torvald reportedly blast RH for releasing the
experimental version?

I suppose if it were that bad, then 7.1 wouldn't have shipped with it.
</quote>

I think Linus was upset at RH breaking object compatibility, combined
with forcing the system to have two compilers, not at the quality of
code. That combined with the fact that you can't compile most kernels
with the newer compiler (there are several kernels that compile right
with 3.x, but only with some configurations; it appears 2.4.10-pre12 is
a point where there is some effort to make it completely 3.x compilable,
but I'm not sure if it is reality yet...but Linus is pushing harder now
to make 3.x and newer kernels compatible). Alan Cox has all along said
the 2.96 version that RH released has many bug fixes over 2.95, and I
guess it is also tested/patched more than what the GNU cvs 2.96 has. In
short, it was a big inconvenience to deal with RH using that compiler,
while the rest of the world did something else. At least that is my
speculation after watching some of the kernel dev list for a while.

D. Stimits, stimits at idcomm.com

> 
>   Anyway, a thing to check is what you are linking against.  Can you
> reproduce the problem in a simple example that does not link against
> external libs other than the gcc standard ones?
> 
> Scott
> 
> "Keith C. Herold" wrote:
> >
> > I have a curious problem.  I know that 7.1 shipped with an "experimental"
> > version of the gcc, but what problems exist beyond just trying to compile
> > the kernel?  I ask because I am having a tremendous amount of trouble
> > compiling simple code, that seems to work correctly.  I have also had
> > trouble compiling code that is supposedly tested against 7.1 (no missing
> > libraries, either).
> >
> > For example, I am trying to retrieve an Entry from a class called Dataset.
> > The copy and assignment constructors for Entry are implemented correctly
> > (according to my testing :) ), and Dataset stores them in a list.  When I
> > try to retrieve one item from the list using a list iterator in one
> > particular function, it segfaults.  Every other function seems to operate
> > correctly, and the various lists are populated with valid data.
> >
> > Is there something about the 7.1 gcc that you folks know of that causes this
> > problem?  I have looked on the gnu web site, but nothing jumps out.
> >
> > --Keith
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug