macOS dynamic shared module extension probably shouldn't default to .dylib or allow both .dylib and .so

[saxbophone]

In the README, you specify that the file extension dylib looks for to load macOS shared modules is .dylib.

Unfortunately, there seems to be a mixture of uses of both .dylib and .so for these kinds of shared objects in macOS.

Interestingly, CMake uses .dylib for shared libraries, and .so for shared modules (the kind that are only intended for loading at runtime, and cannot be linked to).

Sample output from building one of my projects with CMake where I have two duplicate libraries, one SHARED and one MODULE:

[ 76%] Linking CXX shared library libgbfp.dylib
[ 82%] Linking CXX shared module libgbfpm.so

See also this CMake issue: https://gitlab.kitware.com/cmake/cmake/-/issues/21189

I feel like the best solution may be to check for both extensions on macOS. What do you think?

[martin-olivier]

Hello @saxbophone

If i'm not wrong, CMake is holding .so as default extension for modules on MacOS for compatibility issues:

Changing the MODULE library suffix to .dylib (instead of .so) on macOS will require a policy for compatibility.

from https://gitlab.kitware.com/cmake/cmake/-/issues/21189

I feel like the best solution may be to check for both extensions on macOS. What do you think?

I think It could lead to security issues, A strict behavior must be defined, on witch precise shared objects will be looked for by dylib

[saxbophone]

I think It could lead to security issues

Such as my program loading a maliciously-placed alternative plugin rather than the one I intended? Fair enough, what about providing an override instead? .dylib is indeed the most common extension for loadable bundles that I've seen in the lib directories on my mac, but I have seen a few that use .so

[martin-olivier]

Such as my program loading a maliciously-placed alternative plugin rather than the one I intended? Fair enough, what about providing an override instead?

Yes, currently the constructor of the class is not permissive enough for this type of customization. There is the same issue for a shared library build using mingw on windows, that will have the lib prefix, unlike if it was build with msvc where no prefix will be added.

If you have any suggestions on how the dylib class constructor API should be redesigned to allow this type of customization, you are welcome

[bugdea1er]

@martin-olivier What if we could have an #ifdef with some option to choose either dylib or so? This can also be wrapped in a cmake option

[saxbophone]

@martin-olivier What if we could have an #ifdef with some option to choose either dylib or so? This can also be wrapped in a cmake option

IMO making it a compile-time option is an inflexible option, I think this should be an option that can be selected independently of the build-system. Probably as a constructor argument.