projects / ceph.git / blame
| Commit | Line | Data |
|---|---|---|
| 7c673cae FG |
1 | [/ |
| 2 | Copyright 2014 Renato Tegon Forti, Antony Polukhin | |
| 3 | Copyright 2015 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 | ||
| 8 | [section:limitations Limitations] | |
| 9 | ||
| 10 | Some platforms and compilers do not provide all the required functionality to have a fully functional Boost.DLL. | |
| 11 | Such compilers are mentioned in this section along with possible workarounds for those limitations. | |
| 12 | ||
| 13 | [section Exporting weak symbols (Fails on MinGW, Android)] | |
| 14 | Some versions of Android, `MinGW` and `ld` on Windows platform fail to mix `__dllexport__` and `weak` attributes. This leads us to situation, | |
| 15 | where we must explicitly specify translation unit in which [macroref BOOST_DLL_ALIAS] is instantiated, making all other | |
| 16 | [macroref BOOST_DLL_ALIAS] declarations with that alias name an `extern` variable. | |
| 17 | ||
| 18 | Unit that must hold an instance of [macroref BOOST_DLL_ALIAS] must define [macroref BOOST_DLL_FORCE_ALIAS_INSTANTIATION] | |
| 19 | before including any of the Boost.DLL library headers. | |
| 20 | ||
| 21 | You may explicitly disable export of weak symbols using [macroref BOOST_DLL_FORCE_NO_WEAK_EXPORTS]. This may be usefull for working | |
| 22 | around linker problems or to test your program for compatability with linkers that do not support exporting weak symbols. | |
| 23 | [endsect] | |
| 24 | ||
| 25 | [section User defined section names (Fails on SunOS + Oracle Solaris Studio Compilers)] | |
| 26 | Some platforms ignore section attributes, so that querying for a symbols in a specified section using [classref boost::dll::library_info] may return nothing. | |
| 27 | [endsect] | |
| 28 | ||
| 29 | [section:multithread Thread safe library loading (Fails on FreeBSD, MacOS, iOS and some other)] | |
| 30 | On some platforms `dlopen`,`dlclose` and some other functions assume that they won't be called concurrently. | |
| 31 | ||
| 32 | Platforms that certaly have that issue are FreeBSD, MacOS, iOS. | |
| 33 | ||
| 34 | Platforms that certaly do not have such issue are Windows, Linux+glibc, Android, QNX. | |
| 35 | ||
| 36 | Other platforms are under question. If you're using one of the platforms that are not listed (for example Linux+busybox), | |
| 37 | you may run the `shared_library_concurrent_load_test` test to detect the issue: | |
| 38 | ``` | |
| 39 | cd boost_folder/libs/dll/test | |
| 40 | ../../../b2 -a shared_library_concurrent_load_test | |
| 41 | ``` | |
| 42 | [endsect] | |
| 43 | ||
| 44 | [section:nested Nested Function Definitions] | |
| 45 | ||
| 46 | If a function is defined inside the class-definition it may be interpreted as always-inline which can lead to the function not being exported at all. This does however differ between between compilers. | |
| 47 | ||
| 48 | [endsect] | |
| 49 | ||
| 50 | [endsect] | |
| 51 | ||
| 52 |