* The engine can now be built with MinGW-w64 configured with --threads=win32.
This is the case for i686-w64-mingw32-g++ and x86_64-w64-mingw32-g++
distributed with the last versions of Cygwin compatible with Windows XP
(www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html).
The MinGW-w64 toolchains are very powerful, just like their gcc counterparts.
Even the ones with win32 threading model (as opposed to posix threading model),
while not able to use std::thread, can still build-and-use Boost.Thread.
(which, arguably, is more powerful than the Standard counterpart
for example with its support for thread interruption
-- which is less intrusive than the one offered by C++20 std::jthread).
For Windows XP, MinGW-w64 toolchains might be the only ones to support C++11.
Visual C++ has only been supporting C++11 since 2013
(and those versions require-and-often-target newer versions of Windows).
The only part of <thread> we were using was std::thread::hardware_concurrency
(in order to obtain the default value for b2's -j option).
For Windows, we now use dwNumberOfProcessors (in SYSTEM_INFO) and GetSystemInfo.
* - fix iconv detection for boost.locale on iOS
* clang-darwin doesn't need --start-group
* clang-darwin doesn't need -lrt
* Also need appletv to have the same exception. `appletv` is another Xcode clang related platform that would have the same limitations.
combined-x86-power seems to be completely unused and combined is used only in darwin toolset for Objective-C compilation which seems to be broken for 4 years because it uses gcc.set-fpic-options which was removed in 12decb3ce6.
Boost has three libraries that mentions architecture=combined, I have checked they will not brake after this change.
Removes code duplication in darwin and clang-darwin toolsets.
Removes undocumented `<flags>` from several toolsets, there is documented `<compileflags>` that should be used instead.
* features: Support values for instruction-set feature to support Xilinx ZYNQ.
This adds several values for instruction-set (with extensions) to
support various ARM processors associated with Xilinx ZYNQ processors.
These instruction sets are used in various combinations for bare-metal
or FreeRTOS configurations.
* gcc: Support values for instruction-set feature for Xilinx ZYNQ.
`ar s` seems to be widely supported for a very long time:
- at least binutils 2.10 (June 2000)
- at least Darwin 8.0 (April 2005)
- since FreeBSD 3.0 (October 1998)
Note: Most of other (non-widely used) toolsets do not call `ranlib` and do not call `ar` with `s` flag either. I have no idea if they are correct or not, so I am not touching them here.
