Boost.Build 1.73 (required for VS 2022) added the `threadapi` feature
required by Boost.Thread importable via `threadapi-feature` which got
supported by Boost.Thread in 1.66:
3ebd3b6bce
Boost.Iostreams requires a patch from 1.69:
a0c32babd2
Since the update to windows-2022 with msvc-14.3 toolset the CI errors with
> compile-c-c++ bin.v2\libs\filesystem\build\msvc-14.3\release\address-model-64\link-static\threading-multi\codecvt_error_category.obj
> 'cl' is not recognized as an internal or external command, operable program or batch file.
Cause is the use of Bash instead of Cmd shell so do the build in a
separate step.
There is a bug in GCC for 32bit MinGW until version 11.
This causes a use-after free for destruction of `thread_local` variables
that crash the application when the destructor accesses any member.
In the tests it shows up as exit code/status `-1073741819` i.e. `0xC0000005`.
Workaround this by not destructing the `stackstring` instance used to
hold the value of the last `getenv` result.
In the case where any call to `getenv` of a thread yielded a large
value heap memory will be allocated and not freed due to this missing
destructor call causing a memory leak, possibly for each thread.
However values up to some length are stored on stack memory and hence
the missing destructor call does not cause a memory leak as the type is
essentially trivial in this state.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
Fixed by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7fc0f78c3f43af1967cb7b1ee8f4947f3b890aa2
Using `bash` puts `/mingw64/bin` first in the path but the compiler from
`/c/mingw64/bin` is used.
This leads to errors running the tests: "Exit code 0xc0000139" (DLL issue)
which are related to the use of `thread_local`.
Using the powershell works in all cases.
In order to return a non-owning pointer without memory leaks the
function needs to use a static variable.
When calling it from multiple threads there is a data race during the
assignment (and conversion) to this variable.
Fix by making it `thread_local`.
Fixes#189
