Running the tests with “cargo test --target-dir <path>” fails because
"target/" doesn't exist.
Rust 1.57.0 added $CARGO_TARGET_TMPDIR as a scratch directory for
integration tests to use, which Cargo itself won't touch.
Therefore, use $CARGO_TARGET_TMPDIR if it's available, $CARGO_TARGET_DIR
otherwise, and fallback to "target" as a last resort.
Otherwise it leads to a double-free, once in `close` and another time in
`drop`. Curiously this was only a bug on Windows, and Unix code was
fine. Not sure how this happened.
This should make building of this crate significantly faster.
At the same time we also correctly annotate the linkage on the `extern`
block, the way it ought to be.
Sadly there's a regression in tests – the helper scripts no longer
specify the target for which tests are being built. This shall be
addressed in a subsequent commit.
On MSVC Windows loading a TLS symbol will give an address to the
initializer (which when overwritten simply changes the default value new
threads gain for the variable).
On macOS thread locals are misimplemented entirely.
On Linux things "just work", but unknown to what extent, really.
Since the behaviour of using thread local variables as if they were
plain global variables is mostly undefined, lets just not make any
claims of this working.
This allows us to:
a) remove the panics in this library and give the control over what to
do to the user;
b) expose the error conditions to the user better, even if just slightly;
c) implement the modern error handling currently implemented in many of
the modern Rust libraries.
These tests include binary .dll files into the tests directory, because rustc does not allow us to
export symbols through ordinal numbers on Windows, sadly.
Both DLLs contain exactly 1 function (other than DllMain) each, with signature `fn() -> *const
c_char` returning a pointer to "bunny\0".
Thanks to WindowsBunny (aka. retep998) for building the DLLs.
Simonas Kazlauskas