Build problem cross-compiling from LInux to

[John-Nagle]

Cross-compiling on Linux with target Windows. It almost works. Trouble is at

  In file included from /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-sys-0.6.3/build/glslang/StandAlone/StandAlone.cpp:44:
  /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-sys-0.6.3/build/glslang/StandAlone/Worklist.h:89:14: error: ‘mutex’ in namespace ‘std’ does not name a type
     89 |         std::mutex mutex;
        |              ^~~~~
  /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-sys-0.6.3/build/glslang/StandAlone/Worklist.h:41:1: note: ‘std::mutex’ is defined in header ‘<mutex>’; did you forget to ‘#include <mutex>’?
     40 | #include <mutex>
    +++ |+#include <mutex>
     41 | #include <string>

[John-Nagle]

Full listing of build attached. What's going on here is that I'm building Rend3, a Rust portable wrapper for Vulkan. Here I'm trying to build it for Windows while running on Linux. Yes, I realize this is somewhat unusual. Works fine built native on Linux (both Ubuntu 18.04 LTS and Ubuntu 20.04 LTS.) Here, glslang is being built as part of the build process for Rend3.

GCC is complaning that std::mutex is not a type. Even though <mutex> was included. I don't see why that should fail with reasonable default libraries. That's pretty basic. Perhaps somewhere an include path has a problem. It's so close to working.

Fails on both 20.04 LTS and 18.04 LTS, in the same way.

gslang-build-fail.txt

To reproduce the error, install current Rust, get Rend3 from Github, and try to build on Linux with

cargo build --target x86_64-pc-windows-gnu

At first you may get errors telling you to install libraries, depending on what you have installed. Those are easy to get past. Then there's a long compile, failing as shown here.

Please let me know if any further info is required. Thanks.

[greg-lunarg]

Have you looked at this?: https://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type

[greg-lunarg]

I do not consider this a bug since no bad glslang code has been identified. Rather I consider this a request for an enhancement to the build.

I am currently not funded to make this improvement, but I am open to a PR that solves this problem and maintains current capability.

[John-Nagle]

Ah. That explains the problem. Thanks. Looks easy to fix for someone who understands the gslang build system.

(I don't want to dig into their build system; I'd probably break some other platform fixing this one.)

[JohannesKauffmann]

This is problem only when using GCC with the win32 threading model. When using the posix threading model, everything is fine.

On my system (Ubuntu WSL), this can be tested using update-alternatives to switch to the win32 threading model:

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