Forum

Results 1 to 4 of 4
  1. #1
    Join Date
    September 2005
    Location
    Germany / Dortmund
    Posts
    1,376

    RTLD_GLOBAL in dlopen of plugins on unix

    Currently all symbols of a loaded plugin are hidden on unix systems.

    I'll noticed, while playing around with the plugin sdk, implementing a little python plugin (the plugin embeds python / is linked with -lpython). That's just fine and works in the first place.

    But if you try to import some python modules (eg. from your local python installation), the import will break, because the external module can't find the python symbols. The module links python as shared library, assuming the python interpreter will provide the necessary symbols.

    But in this specific case, the module can't find them, and please take "find" in its literal sense, because the symbols are only hidden (the plugin itsself linked with python, remember? ). I guess because the plugins are loaded with dlopen("plugin.so", xx | RTLD_LOCAL)!?

    I've read in some WIN API articles, that symbols of shared windows libraries are always shown, so please can we have that "feauture" on *nix, too?

    A dirty hack with LD_PRELOAD=mylib.so or LD_PRELOAD=libpython.so is possible (and works), but is not very conveniant.

  2. #2
    Join Date
    June 2002
    Location
    Netherlands
    Posts
    1,049
    I am not sure if this would be a good idea. To be honest I do not have much experience with these params.

    Let me try to summarize your problem, to see if I understand it.
    You plugin (dynamically?) links python. While running, your plugin then imports a python module. I am assuming this uses dlopen internally somewhere, correct? This action then fails because these python modules depend on symbols (which libpython exports) being available. But they are not. Correct?

    Reading man:
    RTLD_LOCAL
    This is the converse of RTLD_GLOBAL, and the default if neither flag is specified. Symbols defined in this library are not made available to resolve references in subsequently loaded libraries.

    RTLD_GLOBAL
    The symbols defined by this library will be made available for symbol resolution of subsequently loaded libraries.
    So first of all, I can confirm that we (implicitly) use RTLD_LOCAL (At least on linux).
    RTLD_GLOBAL sounds dangerous to me. If I read it correctly, other shared objects that we open after this action also have access to these symbols. That sounds good for your application. But it also means other plugins see your symbols. That sounds less than optimal. And then what happens if 2 plugin writers decide to export the same (named) symbol? In fact they already do (all the required ts3plugin_* functions).

    Perhaps I need to read into lookup scopes.

    Also, in this document, section 1.5.4 it states that RTLD_GLOBAL should be avoided.

    In conclusion, I am not sure if this would be a good idea.

  3. #3
    Join Date
    June 2002
    Location
    Netherlands
    Posts
    1,049
    One possible work around for you, if you feel adventurous, would be to dynamically load python on your plugin. You could then use dlopen("python", RTLD_LAZY | RTLD_GLOBAL)

    Here is a nice thread about it. http://www.gossamer-threads.com/list..._view_threaded
    It also explains why it works on windows
    Last edited by nwerensteijn; September 5th, 2013 at 05:16 PM. Reason: wrong url

  4. #4
    Join Date
    September 2005
    Location
    Germany / Dortmund
    Posts
    1,376
    Quote Originally Posted by nwerensteijn View Post
    ...
    Let me try to summarize your problem, to see if I understand it.
    You plugin (dynamically?) links python. While running, your plugin then imports a python module. I am assuming this uses dlopen internally somewhere, correct? This action then fails because these python modules depend on symbols (which libpython exports) being available. But they are not. Correct?
    ...
    Correct, except that I want to link statically to avoid external dependencies.

    Dynamic linking would be a workaround, yes of course, but with external dependencies.

    It also explains why it works on windows
    I'm not familiar with windows handling shared libraries, I read that symbols are always exported globally, but that's not important here.

    Anyway, thanks for the reply.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. New to TeamSpeak plugins, looking for MULTIPLE plugins :)!
    By Mycelus in forum Client Plugins / Lua Scripts
    Replies: 3
    Last Post: February 5th, 2014, 08:01 PM
  2. Replies: 4
    Last Post: February 28th, 2012, 10:48 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •