Re: c++/8889: g++ 3.2.1 (also 3.2 it) miscompile Qt

[Felix von Leitner <felix-gcc at fefe dot de>]

Thus spake bangerth@dealii.org (bangerth@dealii.org):
> State-Changed-From-To: open->feedback
> State-Changed-By: bangerth
> State-Changed-When: Mon Dec 16 11:26:23 2002
> State-Changed-Why:
>     I'm still leaning with Volker's ABI theory. What one
>     would need to check is what libraries Qt actually pulls
>     in. For example, on my system these are:
>     tmp/g> ldd /usr/lib/libqt.so.3
>             libpng.so.2 => /usr/lib/libpng.so.2 (0x40618000)
>             libz.so.1 => /lib/libz.so.1 (0x40649000)
>             libGL.so.1 => /usr/lib/libGL.so.1 (0x40658000)
>             libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4080f000)
>             libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40826000)
>             libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4083e000)
>             libdl.so.2 => /lib/libdl.so.2 (0x40848000)
>             libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4084c000)
>             libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4085a000)
>             libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x4091a000)
>             libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x40920000)
>             libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4094a000)
>             libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x4098a000)
>             libm.so.6 => /lib/libm.so.6 (0x409d7000)
>             libc.so.6 => /lib/libc.so.6 (0x409fa000)
>             libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40b22000)
>             libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40b70000)
>             /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

As you noted yourself, the only relevant library is libstdc++, which in
this listing obviously is the wrong one.  In my case it's libstdc++.so.5.
Please compile Qt yourself with gcc 3.2.1 and see if you can reproduce
the problem.  That should be the first prudent cause of action, I think.

Has anyone ever successfully compiled Qt 3.1 with g++ 3.2.1?
I use glibc 2.2.5 because the current glibc 2.3 versions all dump core
in the compilation process (I opened a glibc bug for this).
I used the default Qt options and I used the cxa atexit switch that is
recommended in the gcc web pages for 100% ABI compliance.

It should be a trivial exercise to try to reproduce my problem.  I'm not
using some obscure platform or anything.  Just default or recommended
flags for the involved major packages.  If anyone else was able to
successfully compile these packages, that would be enough for me.  No
need to tell me to look for stuff I already looked at.

>     On my system, these libraries all contain no C++ symbols,
>     except libstdc++, of course, but you should repeat this
>     with the executables/libraries that fail for you.

No, I shouldn't.
These are no obscure projects from some Joe Schmoe.  I used standard
packages and default flags.  It ought to be a matter of seconds to find
someone in the gcc team who compiled these packages with the current
gcc.  I assumed these packages are important enough to be on the
pre-release build process anyway.

And before someone asks: no, I am not overclocking my machine.
I am not using unstable or CVS versions of anything.
I just want to run a system using the latest version of each of the
major packages, including binutils, gcc, glibc and Qt.  That ought to be
possible, right?  I mean, come on, Qt is the most important C++ project!
For many people it is the only reason to install C++ support at all!

Are you telling me that noone has compiled Qt with the current gcc and
binutils yet?