Plugins use PluginName.so on macos instead of libPluginName.dylib ?

[TrevorCash]

Hi Mosra,

I am working on updating the conan package for magnum. when conan generates some of its cmake glue code - it expects that the lib names (on mac) start with "lib" ie libPluginName.so, Is there a reason for this?

In particular cmake throw this when using conan's cmake glue:

CMake Error at build_Release/conanGenerated/cmakedeps_macros.cmake:67 (message): Library 'AnySceneConverter' not found in package. If 'AnySceneConverter' is a system library, declare it with 'cpp_info.system_libs' property Call Stack (most recent call first): build_Release/conanGenerated/Magnum-Target-release.cmake:28 (conan_package_library_targets) build_Release/conanGenerated/MagnumTargets.cmake:24 (include) build_Release/conanGenerated/MagnumConfig.cmake:16 (include) build_Release/_deps/magnum_integrations-src/CMakeLists.txt:62 (find_package)

because AnySceneConverter is names AnySceneConverter.so. changing to libAnySceneConverter.so makes it work.

-Trevor

[mosra]

Yes, the reason is that those aren't libraries that are meant to be linked, those are dynamic modules loaded from the filesystem at runtime, and dynamic modules are still *.so on Mac, not *.dylib.

In other words, the buildsystem shouldn't need to care about them at all, it's all handled by dlopen() by the plugin manager at runtime. They just need to be placed in correct subdirectories (magnum/importers/ etc.) of the library/binary dir so it can find them. OTOH, if plugins are built as static, they are meant to be linked, but they still reside in subdirectories and not the main library dir -- doing so would cause a lot of headaches with conflicting names.

Similar case is for example with Qt's image loading plugins, if you want to look at how the packaging is done elsewhere. Unfortunately tt's been quite a while since I dealt with that Conan recipe, so I don't know what's actually being done there for plugins.

[TrevorCash]

Ok Thank you. current solution in my case is to add the "lib" in front as part of conan's packaging process,

[mosra]

But that'll make them not found correctly by the plugin manager, breaking all workflows where dynamic plugins are involved, so even basic image loading. Linking them directly to the final executable and using them as regular libraries is not a supported scenario.

[TrevorCash]

For now I changed it to copying an extra lib for the plugins in my workflow just to get the generated conan cmake scripts to run. Not a great long-term solution. perhaps a conan option will be introduced to make it more flexible