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

List:       kde-core-devel
Subject:    Plugins (Was: Dynamic Linker weirdness. (Long))
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-05-12 22:03:47
[Download RAW message or body]

This was a very good suggestion from David.

It  works quite nice, since the plugins usually only export a single 
function. I tested it with the views in konqeuror.

I think the following options covers all plugins loaded via KLibLoader:
  -export-symbols-regex 'init_.*'

What about predefining a Makefile variable like:

KDE_PLUGIN =  -module -no-undefined -export-symbols-regex 'init_.*' 

All plugins (cq. parts) only need to add $(KDE_PLUGIN) to their LDFLAGS.

Cheers,
Waldo

On Fri, 12 May 2000, David barth wrote:
> Another option could be to use
>
> libtool ... -export-symbols my_plugin_exported_symbols.sym
>
> to prevent symbol clashes. It's more complex to handle for the plugin
> writer, but it forces one to really think about the _public_ API a
> plugin should export.
>
> Waldo Bastian a écrit :
> > Hiya,
> >
> > Just wanted to let you know that I encountered some problems with kdeinit
> > in conjunction with dlopen. This seems to be similair to the problems
> > reported earlier with khtmlview and some other konqueror plugin.
> >
> > I had a crash with KWin when calling ~Client(). This only happened when
> > kwin was started via kdeinit. Not when started from the command line.
> >
> > There are two major differences between execing kwin and loading kwin via
> > kdeinit:
> > 1) started via kdeinit, the process is linked against more libraries than
> > strictly required by kwin itself.
> > 2) started via kdeinit, kwin.so is loaded via dlopen(). When exec'ed,
> > kwin.so is loaded by ld.linux-so.
> >
> > Both these two differences played a role in this case:
> > A) kdeinit links against KIO, which links againtst libfam when available.
> > libfam defines the class "Client". This resulted in a name clash.
> >
> > B) When kwin.so is loaded by ld.linux-so, symbols are looked up in
> > kwin.so first. However, when kwin.so is loaded with dlopen, it seems like
> > symbols are looked up in other libs first. I think this is a bug.
> >
> > B) seems to be the same bug which caused one konqueror plugin to resolve
> > symbols to another plugin. With devasting results at the moment the
> > plugin gets unloaded.
> >
> > In the plugin case I think this could be prevented by using the 
> > RTLD_GLOBAL flag of dlopen:
> >
> >  RTLD_GLOBAL may be or'ed with flag,  in  which  case
> >        the  external  symbols defined in the library will be made
> >        available to subsequently loaded libraries.
> >
> > libltdl _always_ uses RTLD_GLOBAL. However, I think this is undesired
> > when loading plugins. We do not want to make symbols of one plugin
> > interfere with symbols of another plugin. (Since the plugins might have
> > been developed in parallel there is no way to check for symbol clashes)
> >
> > Executables use the -rdynamic flag to regulate whether their own symbols
> > should be exported to subsequently loaded libraries. Only executables
> > which define a plugin API require this flag. The -rdynamic flag is
> > comparable to the RTLD_GLOBAL option for libraries.
> >
> > Based on this, I propose that libtool should support the -rdynamic flag
> > for libraries as well. When present, the library should be opened with
> > the RTLD_GLOBAL flag. In all other cases, the library should be opened
> > without RTLD_GLOBAL flag.
> >
> > Cheers,
> > Waldo

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