POSIX threads or Windows threads?

help
1

For target x86_64-pc-windows-gnu, does Rust use POSIX threads or Windows threads when cross-compiling Linux->Windows? Documentation is silent on this.

Why? I'm trying to get the Tracy profiler to compile for Linux->Windows, and it's getting a compile error which indicates a conflict in this area. My own program works cross-platform without profiling, but if I add the profiling crate it will not compile. The problem has been narrowed down to the version and options of MinGW in use. Both I and the developer of the Rust crate for interfacing to Tracy are unclear on this.

mingw-options
mingw-options1866×842 194 KB

All the MinGW compilers. I have all the flavors installed and get to pick one.

The compiler is invoked by using the cc crate. You tell it what you want, and it figures out what compiler to use. But the cc crate documentation does not mention the choice of thread implementation.

The tracy-client-sys crate builds the C++ part of the tracy client by calling

fn build_tracy_client() {
    if std::env::var_os("CARGO_FEATURE_ENABLE").is_some() {
        set_feature_defines(cc::Build::new())
            .file("tracy/TracyClient.cpp")
            .warnings(false)
            .cpp(true)
            .flag_if_supported("-std=c++11")
            .compile("libtracy-client.a");
        link_dependencies();
    }
}

which generates the compile command

"x86_64-w64-mingw32-g++" "-O0" "-ffunction-sections" "-fdata-sections" "-gdwarf-2" "-fno-omit-frame-pointer" "-m64" "-std=c++11" "-DTRACY_ENABLE" "-DTRACY_MANUAL_LIFETIME" "-DTRACY_DELAYED_INIT" "-o" "/home/john/projects/ui-mock/target/x86_64-pc-windows-gnu/debug/build/tracy-client-sys-65d4fd2536ddc850/out/tracy/TracyClient.o" "-c" "tracy/TracyClient.cpp"

which apparently builds with the wrong thread model.

So how do I tell cc::Build which thread model is needed?

2

From the resources you've linked, it doesn't look like the "threading model" is an option passed to mingw so much as a completely different compiler you invoke. If you're on Debian/Ubuntu, you should be able to do:

sudo update-alternatives --config x86_64-w64-mingw32-g++

which will let you pick the one you want to use by default.

Alternatively, you could invoke the executable you want directly, either x86_64-w64-mingw32-g++-win32 or x86_64-w64-mingw32-g++-posix. I'm not very familiar with cc, but it looks like you can override the compiler to use with its .compiler() method:

if b.get_compiler().is_like_gnu() {
    b.compiler("x86_64-w64-mingw32-g++-posix");
}
3

Good idea. Tried that. Now std::mutex is defined, but I get new undefined errors:

running: "x86_64-w64-mingw32-g++-posix" "-O0" "-ffunction-sections" "-fdata-sections" "-gdwarf-2" "-fno-omit-frame-pointer" "-m64" "-std=c++11" "-DTRACY_ENABLE" "-DTRACY_MANUAL_LIFETIME" "-DTRACY_DELAYED_INIT" "-o" "/home/john/projects/rustcode/rust_tracy_client/target/x86_64-pc-windows-gnu/debug/build/tracy-client-sys-321ed9b25eb951d3/out/tracy/TracyClient.o" "-c" "tracy/TracyClient.cpp"
  cargo:warning=In file included from tracy/TracyClient.cpp:26:
  cargo:warning=tracy/client/TracySysTrace.cpp: In function ‘bool tracy::SysTraceStart(int64_t&)’:
  cargo:warning=tracy/client/TracySysTrace.cpp:360:37: error: ‘TraceSetInformation’ was not declared in this scope; did you mean ‘HeapSetInformation’?
  cargo:warning=  360 |         const auto intervalStatus = TraceSetInformation( 0, TraceSampledProfileIntervalInfo, &interval, sizeof( interval ) );
  cargo:warning=      |                                     ^~~~~~~~~~~~~~~~~~~
  cargo:warning=      |                                     HeapSetInformation

This is going to need attention from the tracy-client-sys crate.

4

Looking at MinGW-w64 - for 32 and 64 bit Windows / mingw-w64 / [813b57] /mingw-w64-headers/include/evntrace.h, TraceSetInformation is only included if WINVER >= 0x0601, that is, Windows 7 or greater. Do you need to make sure the compiler options include -DWINVER=0x0601?

5

I have to check this out with the tracy-client-sys developer. This is getting way too deep into the innards of their package and its upstream C++ code, which is low-level Windows internals stuff.

6

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.