faq.qbk 4.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105
  1. [/
  2. Copyright 2014 Renato Tegon Forti, Antony Polukhin
  3. Copyright 2015-2019 Antony Polukhin
  4. Distributed under the Boost Software License, Version 1.0.
  5. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
  6. /]
  7. [section F.A.Q.]
  8. * [*Question:] Is Boost.DLL thread-safe?
  9. * [*Answer:] Some platforms allow concurrent calls to `dlopen` like functions.
  10. For those platforms Boost.DLL is safe in the manner as all the C++ Standard Library containers are: it is
  11. safe to use different instances of shared_library from different threads even if all the instances loaded the same library. On other platforms it
  12. is not safe to concurrently call any of the functions from Boost.DLL (even a `shared_library::location()` call triggers a race condition).
  13. See [link boost_dll.limitations.multithread Limitations, Thread safe library loading].
  14. [pre
  15. ]
  16. * [*Question:] Why on Linux symbols from one plugin are seen in another? Can't get symbol with same name from right plugin!
  17. * [*Answer:] You've run into the symbol shadowing problem. Compile your plugins with "-fvisibility=hidden"
  18. flag and take a look to the Tutorial section.
  19. [pre
  20. ]
  21. * [*Question:] How Unicode (Windows) is handled?
  22. * [*Answer:] Boost.DLL supports Unicode, so that you could provide Unicode paths to it.
  23. [pre
  24. ]
  25. * [*Question:] Can I open an executable file?
  26. * [*Answer:] Yes, you can. Symbols need be exported using in the executable using `BOOST_SYMBOL_EXPORT`
  27. or `BOOST_DLL_ALIAS`. You can call `shared_library(program_location())` to load yourself. Refer to
  28. the Tutorial section for more info. You can also query executables, just provide a path to the executable
  29. to `library_info` class.
  30. [pre
  31. ]
  32. * [*Question:] What if I specify wrong type in `shared_library::get<T>` or `import<T>`?
  33. * [*Answer:] Usually you'll end up with `Segmentation Fault`. However it is safe to make types
  34. more strict, for example making `const int` from an `int` will not harm.
  35. [pre
  36. ]
  37. * [*Question:] Does your library guarantee ABI stability of methods?
  38. * [*Answer:] Library only guarantees that alias names created using the `BOOST_DLL_ALIAS` macros
  39. will not change with the change of compiler or platform. You must take care of functions ABI and API
  40. stability by your own.
  41. [pre
  42. ]
  43. * [*Question:] Are there any function signature restrictions for the exported/imported functions?
  44. * [*Answer:] No. You may import/export functions with any signature and any return parameter.
  45. [pre
  46. ]
  47. * [*Question:] I have 2 plugins that use same shared library. Would be the shared library loaded twice?
  48. * [*Answer:] No. Pugins will share the shared library instance.
  49. [pre
  50. ]
  51. * [*Question:] I have 2 plugins each of them must work with it's own version of `libsome_library` shared library. How to achieve that?
  52. * [*Answer:] Avoid such situations by statically linking in the libsome_library into each plugin and loading plugins with `load_mode::rtld_deepbind`.
  53. [pre
  54. ]
  55. * [*Question:] How to load a shared object from memory??
  56. * [*Answer:] All existing OS avoid loading shared libraries directly from userspace memory, so you'll find no syscall for such case. Currently Boost.DLL provides no means for honest loading shared objects from memory. This requires reimplementing dynamic linker logic in userspace for all the platforms, which is a huge amount of work and very error-prone. However working patches are welcomed!
  57. Workaround would be to write plugin into a temporary file in RAM and load plugin from it:
  58. ```
  59. #include <boost/filesystem.hpp>
  60. #include <boost/dll.hpp>
  61. using namespace boost;
  62. dll:shared_library load_from_memory(unsigned char* data, std::size_t size, const filesystem::path& tmp_plugin_path = filesystem::unique_path() / "libplugin.so") {
  63. const filesystem::path plugin_location = filesystem::temp_directory_path() / tmp_plugin_path;
  64. filesystem::create_directories(plugin_location.parent_path());
  65. filesystem::ofstream ofs(plugin_location, std::ios::out|std::ios::bin|std::ios::trunc);
  66. ofs.write(data, size);
  67. return dll::shared_library(plugin_location);
  68. }
  69. ```
  70. But there's no guarantee that `filesystem::temp_directory_path()` will actually write to RAM, that's very platform dependent.
  71. [pre
  72. ]
  73. * [*Question:] I have found a bug, how do I notify?
  74. * [*Answer:] Create an [@https://github.com/apolukhin/Boost.DLL/issues issue at GitHub] with a detailed description.
  75. [endsect]