Upgrade to the high-level ittapi v0.3.0 crate

[bnjbvr]

This is using the new fancy ittapi high-level crate that we've worked on, @abrown @jlb6740 and myself, and it upgrades to the latest version.

Could someone please test it locally and confirm it works for them? On my machine I get a weird failure that I also hit on main, not sure what's going on:

Assertion failed: tool:1328: g_instr_global.is_libpthread_so_loaded == 0 : g_instr_global.is_libpthread_so_loaded == 1
. Please contact the technical support. vtune: Error: Assertion failed: tool:1328: g_instr_global.is_libpthread_so_loaded == 0 : g_instr_global.is_libpthread_so_loaded == 1
. Please contact the technical support. 

[bnjbvr]

Ah, seems compilation of the ittapi crate on windows is broken. Any ideas @abrown @jlb6740?

[abrown]

I looked into this but don't know yet how to resolve it: the compilation failure is due to strnlen_s not being available in MinGW by default (it is, after all, a non-standard function). There are some thoughts out there that adding --enable-secure-api will include the headers with this function, but before I add that to ittapi-sys's build.rs, I wanted to be able to reproduce the issue.

Locally I was unable to reproduce: after installing MSYS2 and compiling the ittapi crates with cargo build --target x86_64-pc-windows-gnu, everything seemed to build as normal. When I run cargo test --target x86_64-pc-windows-gnu, I get a different error: linker x86)64-w64-mingw32-gcc not found.

I then attempted to reproduce on ittapi's CI: using a similar setup to the Wasmtime workflow, I added x86_64-pc-windows-gnu as a target in the matrix. With the windows-latest OS, however, the crates built and tests ran. With the windows-2019 OS, then I observe a completely different failure related to libclang.dll being inaccessible.

Any suggestions?

[abrown]

@bnjbvr: since we can't really replicate this, we could just disable the ittapi dependency for MinGW builds?

[bnjbvr]

@abrown Need to check but I think that we do use this target to cross-compile internally. If so at least I might find people who could poke at this, maybe...

[bnjbvr]

Seems we don't use it, so yeah we could disable ittapi on mingw then, and if someone wants to support that, they would need to contribute a patch. Does it sound acceptable?

[abrown]

Does it sound acceptable?

It sounds acceptable to me, though others feel free to comment. I'm not sure how much energy to put into MinGW since I don't use it much (ever!) and I wonder sometimes if it has been obsoleted by WSL.

[alexcrichton]

Personally I find managing platform-specific exceptions and such to APIs not easy to maintain over time. To that end I would prefer to see this solved. It looks to me like MinGW doesn't provide the strnlen_s function which is the source of this error. The only reason we're seeing this now is probably because something in the ittapi crate is calling a function we didn't call before in the C library and the C function requires strnlen_s or something like that.

Locally I was unable to reproduce: after installing MSYS2 and compiling the ittapi crates with cargo build --target x86_64-pc-windows-gnu, everything seemed to build as normal

That's because when you build an rlib it doesn't actually link anything, so this doesn't verify that symbols are actually present on the system.

When I run cargo test --target x86_64-pc-windows-gnu, I get a different error: linker x86)64-w64-mingw32-gcc not found.

If the ) there isn't a typo then that's a misconfigured compiler somewhere. Otherwise this may mean you're not running the command in an MSYS2 shell or something like that. Basically if the linker isn't being invoked you won't be able to reproduce this issue.

With the windows-latest OS, however, the crates built and tests ran

I don't think that the CI is configured correctly which is why this seems to work. In the logs I see:

     Running tests\bindgen-up-to-date.rs (target\debug\deps\bindgen_up_to_date-ae57c289f5ef2e2d.exe)

but if you're cross compiling the path to the binary should be target\x86_64-pc-windows-gnu\debug\deps\.... You added this to the CI configuration:

    - run: echo CARGO_BUILD_TARGET=${{ matrix.target }} >> $GITHUB_ENV
      if: matrix.target != ''

but I don't think that works because the shell you're using is windows cmd or powershell (I dunno which) and probably doesn't use $foo for environment variables. This I believe means you're not actually configuring Cargo for cross-compilation.

[bnjbvr]

Very good call, @alexcrichton! Managed to reproduce the compilation error on ittapi now: intel/ittapi#61

[abrown]

This should be merge-able once GitHub's virtual environment for Windows is updated with the latest version of MinGW: actions/runner-images#5729.

[abrown]

I believe that the updated version of MinGW (which includes the missing strnlen_s definition) has been rolled out to the machines that run the windows-latest CI jobs. Over in intel/ittapi#63 I was able to build ittapi without issues on windows-latest. I'm re-running CI here to check if we can actually merge this now.

[alexcrichton]

I believe the issue here is that we're pinned to windows-2019 (see #3864 for info on that) so we're not getting updates. I'd reiterate though that there's no requirement to get this working on all platforms. Disabling this on mingw is fine.

[bnjbvr]

Just added a commit that disables this on windows + mingw, and it seems to compile fine. Unfortunately there's an unrelated MacOS build error (Github says the CI run has been cancelled), and I can't request a retry, so could anyone with the right authorization bits please do that?