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

List:       kde-core-devel
Subject:    Re: [Fwd: Re: Dynamic Linker weirdness.] (Long again)
From:       Michael Matz <matz () ifh ! de>
Date:       2000-05-16 22:11:55
[Download RAW message or body]

Hi,

On Tue, 16 May 2000, Waldo Bastian wrote:
> > > (Checked! After linking the plugin against kwin.la, it can be loaded
> > > again by kwin)
> >
> > That makes me wonder ;) If kwin.so doesn't export symbols how can the
> > plugins link against that symbols. 
> 
> Because you link the plugin against kwin.so. That doesn't make much 
> difference, because kwin.so is loaded already anyway. The only difference is 
> that now the symbols of kwin.so will be available to the plugin.

Hmm. Let's see if I get it. You load kwin.so in klauncher without
RTLD_GLOBAL (or so), so there the symbols are not exported. Then you link
the plugins against kwin.so as if it were a shared lib, and thereby making
kwin.so a dependency library for that pluging. So if that plugin is loaded
by kwin (that one loaded by klauncher), the loading mechanism makes sure,
that all shared libs that plugin depends on are also loaded (of course),
and so loads kwin.so "again". Of course not really because it's already
loaded, but at least it takes up the symbol table again from kwin.so (that
on disk), and rebinds the plugin to that. So far so good.

Hmm now what happens with those symbol tables loaded for the plugins. Do
they end up anywhere (and cause problems for later loaded plugins)? Or are
they also thrown away? I know, you load the plugin without RTLD_GLOBAL,
but as far as I understand it only applies to the symbols exported by
_only_ that plugin. So symbols of dependence libs would still be made
known. I don't know if it is so. If that would be the case, we would have
won nothing (well, the loading of conflicting symbols take place a little
later, but it would nonetheless happen). I'm only pointing out potential
problems, all hypotetical until someone test ;)

> > [... my version map excitement ...]
> 
> Does that control which symbols end up in the "dynamic symbol table"? From 
> what I understand, it is not possible with linux to control that.

It _is_ possible, but not with libtools -export-symbols-regex. As I said,
I first tried to achieve the goal with objcopy and localizing per hand,
succeeded but feeled that it would be a rather ugly solution (I mean
_really_ ugly ;). I then asked them of other possibilities, and became
aware of version maps, tried them, and yes, they really do what we want.
Exactly. The downside is, that I don't know how well they are supported by
older binutils versions.

As there was a bug in the C++ support of version maps in ld, which took me
some time to figure out, I think I'll not have time to write version map
support today. It has to wait for tomorrow (the logical tomorrow, after
the sleep phase, which is today, since ten minutes ;) )


Ciao,
Michael.

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