Anybody got an idea what the issue is? Maybe it uses the wrong gcc compiler?
What I don’t really get from the installation instructions is how the meson build uses the MSVC compiler from the visual studio installation. I’m pretty sure my mason run uses the gcc from MinGW. Could this maybe be the issue?
I’m really thankful for any help.
"gcc" "-Isubprojects\libuv-v1.43.0\libuv.a.p" "-Isubprojects\libuv-v1.43.0" "-I..\..\..\subprojects\libuv-v1.43.0" "-I..\..\..\subprojects\libuv-v1.43.0\include" "-I..\..\..\subprojects\libuv-v1.43.0\src" "-fdiagnostics-color=always" "-DNDEBUG" "-D_FILE_OFFSET_BITS=64" "-O3" "-pthread" "-fno-strict-aliasing" "-DWIN32_LEAN_AND_MEAN" "-D_WIN32_WINNT=0x0602" -MD -MQ subprojects/libuv-v1.43.0/libuv.a.p/src_win_async.c.obj -MF "subprojects\libuv-v1.43.0\libuv.a.p\src_win_async.c.obj.d" -o subprojects/libuv-v1.43.0/libuv.a.p/src_win_async.c.obj "-c" ../../../subprojects/libuv-v1.43.0/src/win/async.c
In file included from ../../../subprojects/libuv-v1.43.0/src/win/internal.h:29:0,
../../../subprojects/libuv-v1.43.0/src/win/winapi.h:4534:19: error: unknown type name 'PRTL_OSVERSIONINFOW'
../../../subprojects/libuv-v1.43.0/src/win/winapi.h:4743:8: error: unknown type name 'sRtlGetVersion'
extern sRtlGetVersion pRtlGetVersion;
Maybe some addition to this and why I think mason somehow uses the wrong compiler. I got the two path variables defined where make and the compilers are located.
When I remove the path to the compilers C:\MinGW\bin mason throws an error about unknown linker.
Build type: native build
Project name: mediasoup-worker
Project version: undefined
C compiler for the host machine: gcc (gcc 6.3.0 "gcc (MinGW.org GCC-6.3.0-1) 6.3.0")
C linker for the host machine: gcc ld.bfd 2.28
meson.build:1:0: ERROR: Unknown linker(s): [['gcc-ar'], ['ar'], ['gar']]
The following exception(s) were encountered:
Running "gcc-ar --version" gave "[WinError 2] The system cannot find the file specified"
Running "ar --version" gave "[WinError 2] The system cannot find the file specified"
Running "gar --version" gave "[WinError 2] The system cannot find the file specified"
C++/CLI is for compiling .NET assemblies, it is not important. Something seems to be wrong with the Windows SDK headers. In libvu/win, async.c includes internal.h, internal.h includes winapi.h, winapi.h includes windows.h from SDK, which includes windef.h, windef.h includes winnt.h, and there it is - a declaration of PRTL_OSVERSIONINFOW. It is worth to check the part of this chain in the SDK that is used by GCC.
OK, so in the parameters you have --vsenv, which forces Meson to set up MSVS environment, but it doesn’t seem to be able to see that MSVS installed at all, which is unusual. GCC on Windows is unsupported configuration, so whatever error happens there we don’t care too much unless you want to fix it yourself.
The question now is how to make it see Visual Studio. I’ll try to install a newer version in a VM and see if it works there.
Sorry for the inconveniences. I uninstalled MinGW and only choose msys-base but I still get the unknown linker error. It seems meson really doesn’t see my Visual Studio. Therefore I also opened an issue in the meson repo https://github.com/mesonbuild/meson/issues/9864.
Not very unusual if you look at the file vsenv.py:
if 'MESON_FORCE_VSENV_FOR_UNITTEST' not in os.environ:
if 'Visual Studio' in os.environ['PATH']:
I.e. if it finds a substring “Visual Studio” anywhere in the PATH, it just breaks from the procedure, and --vsenv has no effect at all. Exactly what are these people thinking? I am not sure. That if “Visual Studio” is present in the PATH for whatever reason, it is an equivalent of running vcvars*.bat? This is definitely incorrect.
This PR had been merged into the meson 0.62.0, and later the whole library was reshaped in a different way. Its is now at version 1.0.0. Yet, mediasoup still refers to meson 0.61.5, so this issue is not solved. Maybe it is worth to test mediasoup’s installer with a more recent version of meson.
I think we can switch to 1.0.0 or even 1.x as they are not supposed to break backwards compatibility now.
The only significant change I see is that minimal Python version was increased from 3.6 to 3.7 which may potentially rule out some environments, but Python 3.6 is EOL, so IMHO it is acceptable. BTW Python 3.7 will be EOL in June too, so we might bump requirement in our docs to 3.8 right away.