From kde-core-devel  Fri Sep 15 23:08:21 2000
From: Charles <charles () altair ! dhs ! org>
Date: Fri, 15 Sep 2000 23:08:21 +0000
To: kde-core-devel
Subject: Re: Linking kdelibs with libqt-mt again
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=96905926025784

On Fri, 15 Sep 2000, Stefan Westerfeld wrote:
> Hi!
>
> On Fri, Sep 15, 2000 at 11:35:55PM +0200, Stephan Kulow wrote:
> > Rik Hemsley wrote:
> > > I say again, if we don't link kdelibs with libqt-mt on Linux and
> > > FreeBSD then there will be no MT applications for these platforms t=
hat
> > > link to the KDE libraries. I for one would have to convert my Empat=
h
> > > code to pure Qt, which would cripple it as the UI is all kparts.
> >
> > And I still say that it's not the right time to think about it.
> > We can switch it on right after 2.0 and be it that we release KDE 2.1
> > as linking to another Qt for some plattforms. But don't rush that in.
>
> I can't tell wether libqt-mt is binary incompatible to libqt. However,
> I just can add in favour of Rik's argument that libmcop currently is
> unthreaded but links to libpthread anyway, because otherwise there are
> problems with threaded components.

I asked a troll about this a while ago, and the reply was:
libqt is binary compatible with libqt-mt, on Linux.  It's not going to be=
=20
binary compatible with libqt on some other platforms.  This means we need=
 to=20
link to libqt-mt now, or wait until KDE3.

>
> So basically if we want KParts with threading (like a Mozilla KPart or
> something like that), they will get dynamically loaded into our process
> space, and if we want that to work, we have to link libpthread. Sure, w=
e
> can try to postpone this to KDE2.1, but then KDE2.1 will be binary
> incompatible to KDE2.0, and components written for one will not run wit=
h
> the other.
>
> There are things like errno which simply get redefined when doing the
> pthreads stuff, and you can't do one lib like this, and one lib like
> that (at least thats my hands-on experience with mpeglib vs. libmcop,
> which are lt_dlopened together).
>
>    Cu... Stefan