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

List:       kde-core-devel
Subject:    Re: [Fwd: Re: Dynamic Linker weirdness. (Long)]
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-05-14 6:58:21
[Download RAW message or body]

On Sat, 13 May 2000, Michael Matz wrote:
> > > I don't have libfam. So, is there any other way where the error
> > > manifests reproducable?  With which module? It's hard to fix an error
> > > one doesn't see ;)
> >
> > Lars had a crash when unloading konqueror views last week. He may have an
> > easy way to trigger them.
>
> I thought, that had to do with template methods implementations got
> included multiple times in the executable. (Note that these were the same
> implementations). As I said, with the binutils version I use I get no
> duplicates and I couldn't reproduce his problems.
>
> Whereas (if I understood correctly) your problems are coming from
> different implementations of the same global symbol (one in libfam and one
> in kwin).
>
> ... Hmm, I just thought about another problem: Even if we could hide the
> cconflicting symbols in kwin.so (~Client was the problem IIRC), the kwin
> style plugins want to use them, so that isn't going to work. It'll only
> work for plugins that do not load other plugins, or at least whose symbols
> are not used any further.

No, we (KDE) don't want to hide Client in kwin.so, we (fam) want to hide 
Client in libfam. But we (KDE) have basically the same problem with plugins. 
And I believe the template problem was a manifestation of the same problem.
(In the template case the problem did only show up when the plugin was 
unloaded because the implementation of both versions of the template was the 
same, but the bug is that the version in the other lib was used in the first 
place)

> So if we want to load kwin.so by kdeinit, and want to also load libs which
> export symbols which are also exported by kwin and used by kwin plugins,
> we loose in every case. 

Well, libfam shouldn't pollute the namespace by exporting symbols with 
general names like "Client". The problem is how it is going to prevent that, 
if all symbols end up in the lib regardless of -export-symbols.

> Either there are conflicts between kwin and the
> libs, or the plugins can't bind against kwin. 

It's basically a kwin <--> libfam conflict which should be solved in libfam.

> Ugh. May be its time for a
> global KDE:: namespace? At least that would be the cleanest approach and
> solution to all problems (well, nearly all ;) .

No. Two plugins could still define the same templates (within the KDE 
namespace) and cause problems if they get resolved in between plugins.

We can work around those problems when we detect them, but we should be able 
to prevent it from happening in the first place.

Cheers,
Waldo

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