[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Linking kdelibs with libqt-mt again
From:       Charles <charles () altair ! dhs ! org>
Date:       2000-09-15 23:08:21
[Download RAW message or body]

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 that
> > > link to the KDE libraries. I for one would have to convert my Empath
> > > 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 
binary compatible with libqt on some other platforms.  This means we need to 
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, we
> 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 with
> 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

[prev in list] [next in list] [prev in thread] [next in thread]