Re: New KDE's QT-3.1.2 && Sarge's gcc 3.2.3-0pre9 binary incompat?
On Tue, May 20, 2003 at 09:31:26PM +0200, Andreas Pakulat wrote:
> On 20.Mai 2003 - 20:37:38, Dave Lister wrote:
> > Hi there, I've just subscribed to this list - feel free to spank me if
> > I'm too BFUish ;)
> > I've installed new KDE 3.1.2 core libraries (from kde.org) on my SARGE.
> > It was a bit tricky as KDE's Arts is "only" 1.1.2-0 and Sarge's is
> > 1.1.2-1. I've solved this manully and installed WOODY's libvorbis0 to
> > allow KDE's Arts slip in without further dependency problems. So far so
> > good. Now, I have new KDE's Arts, core and QT 3.1.2 libraries and
> > devel headers.
> > I'm using new gcc 3.2.3-0pre9, _not_ Woody's 2.9x, which was used to
> > compile all KDE's binary packages. Everyting seems to work all right,
> > new KDE apps and even my compiled-before-upgrade /usr/local/bin QT apps.
> > The problem is that any qt-based app I try to _compile_ now fails to get
> > linked, because of "undefined references", apparently the ones to
> > exports in libqt-mt.
> > My guess is that gcc 3.2 is somehow "binary incompatible" with older
> > 2.9x and thus, linker fails to resolve all symbols in the 2.9x-compiled
> > libqt-mt.so.3.1.2.
> > First question:
> > Is it possible? If not, what could be the reason?
> Is what possible? To compile your QT apps against a library built with
> 2.9x? No, the so called ABI of 2.95, 3.0, 3.1, 3.2 are all incompatible
> to each other. The KDE and also QT probably used 2.95 to compile so this
I meant if it's possible that gcc 2.95 and 3.2 would be "somehow binary
incompatible" - they are, because of ABI, as you said. That's what I
wanted to know. Thanx.7
> > Second question: Is there any other way than downgrading gcc back to
> > Woody's 2.9x or compiling the whole QT from sources (as I did in the
> > days of unstable 3.1)?
> You don't have to downgrade, export CC=gcc-2.95 and CXX=gcc-2.95, that
> should do. Oh and don't forget to do an apt-get install gcc-2.95, it
> is also available in sarge :) Only the gcc package changes according
> to the transition to gcc-3.2
Ok, I'll do it this way. You were most helpful; thank you, Andreas.