Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PluginManager::Manager::load(): cannot load plugin AssimpImporter #63

Closed
xiconxi opened this issue Aug 12, 2019 · 8 comments
Closed

PluginManager::Manager::load(): cannot load plugin AssimpImporter #63

xiconxi opened this issue Aug 12, 2019 · 8 comments

Comments

@xiconxi
Copy link

@xiconxi xiconxi commented Aug 12, 2019

PluginManager::Manager::load(): cannot load plugin AssimpImporter from "/home/obirt/Code/Render/VIS-magnum/cmake-build-debug/src/magnum-d/importers/AssimpImporter.so": /home/obirt/Code/Render/VIS-magnum/cmake-build-debug/src/magnum-d/importers/AssimpImporter.so: undefined symbol: _ZN6Magnum5Trade16AnyImageImporterC1ERN7Corrade13PluginManager7ManagerINS0_16AbstractImporterEEE

@mosra mosra added this to the 2019.0b milestone Aug 12, 2019
@mosra mosra added this to TODO in Project management via automation Aug 12, 2019
@mosra mosra mentioned this issue Aug 12, 2019
60 of 60 tasks complete
@xiconxi

This comment has been minimized.

Copy link
Author

@xiconxi xiconxi commented Aug 12, 2019

I'm very sorry to make a mistake for this. I forgot to compile to metadata and copy the same path as AssimpImporter.so

@xiconxi xiconxi closed this Aug 12, 2019
Project management automation moved this from TODO to Done Aug 12, 2019
@mosra

This comment has been minimized.

Copy link
Owner

@mosra mosra commented Aug 12, 2019

Hi, sorry -- I had a reply written but forgot to send it 🙈 Usage of plugins in combination with CMake subprojects is currently everything but ideal. Fixing this is on my short-term roadmap, but not quite there yet.

I just updated Corrade to make this error clearer in mosra/corrade@438fd97 -- now it will warn about the actual error instead of ending up with a cryptic message like this. The ideal fix for this is to not require random conf files and instead have the metadata self-contained in the *.so. Added that to TODOs for the next release.

@xiconxi

This comment has been minimized.

Copy link
Author

@xiconxi xiconxi commented Aug 13, 2019

to get the shared object dependencies, here's some code snippet base on ELF:

#include <dlfcn.h>
#include <elfio/elfio.hpp>
#include <iostream>

int main(int argc, char** argv) {
    ELFIO::elfio reader;
    reader.load(argv[1]);
    auto dynamic = ELFIO::dynamic_section_accessor(reader, reader.sections[".dynamic"]);
    std::cout << "enties num: " << dynamic.get_loaded_entries_num() << std::endl;
    ELFIO::Elf_Xword tag, value;
    std::string entity_str;
    for(int i = 0; i < dynamic.get_loaded_entries_num(); i++) {
        dynamic.get_entry(i, tag, value, entity_str);
        if(tag == DT_NEEDED)
            std::cout << "DT_NEEDED: " << entity_str << std::endl;
        else if(tag == DT_RPATH)
            std::cout << "DT_RPATH: " << entity_str << std::endl;
        else if(tag == DT_RUNPATH)
            std::cout << "DT_RUNPATH: " << entity_str << std::endl;
    }
}

ELFIO

@xiconxi xiconxi reopened this Aug 13, 2019
Project management automation moved this from Done to In Progress Aug 13, 2019
@mosra

This comment has been minimized.

Copy link
Owner

@mosra mosra commented Aug 13, 2019

Problem is, the plugin is not explicitly linked to any of its plugin dependencies at compile-time, so the ELF file can't know what *.sos it depends on -- that's what the metadata file is there for. Plus there isn't always 1:1 mapping from a plugin to its dependencies, sometimes it can be multiple plugins satisfying the same dependency. And, finally, the metadata contain other important information needed by the plugin, in case of AssimpImporter it's various configuration of the import behavior (which can be either overriden from the code or changed directly in the conf file).

Contrary to plugin dependencies, for library dependencies (e.g. the AssimpImporter depending on libassimp.so), the dependency is resolved at compile-time and this "just works" -- when loading the AssimpImporter plugin, it just loads libassimp.so on its own, no need to do anything explicitly there.

@xiconxi

This comment has been minimized.

Copy link
Author

@xiconxi xiconxi commented Aug 14, 2019

What's the meaning of the plugin is not explicitly linked to any of its plugin dependencies at compile-time? plugin is a lib too, I think all the runtime shared object dependencies has been explicitly linked to the plugin. Those default configurations could declare in header, custom configurations using .conf file . Then the .conf files are removed in trival-case. That's what I really recommand for.

@williamjcm

This comment has been minimized.

Copy link
Contributor

@williamjcm williamjcm commented Aug 14, 2019

What mosra said is that plugins aren't linked to other plugins. Only to the libraries they directly depend on.

@xiconxi

This comment has been minimized.

Copy link
Author

@xiconxi xiconxi commented Aug 14, 2019

thank you guys. plugins aren't linked to other plugins

@xiconxi xiconxi closed this Aug 14, 2019
Project management automation moved this from In Progress to Done Aug 14, 2019
@mosra

This comment has been minimized.

Copy link
Owner

@mosra mosra commented Oct 15, 2019

Just FYI: since mosra/corrade@73d3f31, mosra/magnum@3a243a0 and dff98d8, plugins are put in the build directory into a common location, which makes CMake subprojects with default config (i.e., dynamic plugins) "just work". This change should also improve the experience for Windows users as all DLLs are placed next to the executables.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.