I’m currently trying to install mediasoup on windows. I could solve most of the issues I initally had but
I’m stuck at compiling the subproject libuv. I followed all the instructions here https://mediasoup.org/documentation/v3/mediasoup/installation/ but it seems I still have an issue with the c++ compiler.
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.
FAILED: subprojects/libuv-v1.43.0/libuv.a.p/src_win_async.c.obj
"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,
from ../../../subprojects/libuv-v1.43.0/src/win/async.c:25:
../../../subprojects/libuv-v1.43.0/src/win/winapi.h:4534:19: error: unknown type name 'PRTL_OSVERSIONINFOW'
(PRTL_OSVERSIONINFOW lpVersionInformation);
^~~~~~~~~~~~~~~~~~~
../../../subprojects/libuv-v1.43.0/src/win/winapi.h:4743:8: error: unknown type name 'sRtlGetVersion'
extern sRtlGetVersion pRtlGetVersion;
Meson has built-in functionality to find and use the latest MSVS installed by default. We force it to use that mechanism even under MinGW unless you make deliberate extra steps to make it not happen.
Which version of Windows are you on? We use Windows Server 2019 (roughly the same as Windows 10) in CI for both worker tests and Rust library tests, both work just fine.
Thanks for the response. I’m on Windows 10 Version 21H2 (OS Build 19044.1466). I got Visual Studio 2022 installed and MSVC v143 - VS 2022. Maybe I have to install another MSVC version?
Latest Meson version should support MSVS 2022, but I was only testing 2019 and Windows Server 2019 on GitHub Actions has 2019 by default as well.
libuv’s CI has Windows Server 2022 added already, I’ll take a look later at why it fails to compile for you and if I can reproduce in in CI I’ll try to fix it.
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"
I see you did some tweaks to the PATH that wasn’t mentioned in the installation requirements and sending various snippets of the log output. Can you provide the whole picture?:
all the PATH entries (ideally just those that are mentioned in the installation requirements)
specific commit you are on right now
complete log output start to finish
Also maybe try to use default selection of tools for MSVS (I have no idea if it matters, but maybe something like “C++/CLI support” is important by any chance…
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.
Sure I changed PATH to the ones mentioned but still the same result. I’m on commit e7d4f874275dad69cd584a1b7cdd6be4656d1791.
@snnz You are right C++/CLI is usually used to write wrappers for .NET projects. But besides that I’m really unfamiliar with C++. Can you give me a hint how I can analyse/debug this chain?
System enviroment variables:
Log:
D:\Repos\mediasoup>npm install
> mediasoup@3.9.5 postinstall
> node npm-scripts.js postinstall
npm-scripts.js [INFO] running task "postinstall"
npm-scripts.js [INFO] executing command: node npm-scripts.js worker:build
npm-scripts.js [INFO] running task "worker:build"
npm-scripts.js [INFO] executing command: make -C worker
make: Entering directory `/d/Repos/mediasoup/worker'
/d/Repos/mediasoup/worker/out/pip/bin/meson setup \
--prefix /d/Repos/mediasoup/worker/out/Release \
--bindir '' \
--libdir '' \
--buildtype release \
-Db_ndebug=true \
-Db_pie=true \
-Db_staticpic=true \
--reconfigure \
--vsenv \
/d/Repos/mediasoup/worker/out/Release/build || \
/d/Repos/mediasoup/worker/out/pip/bin/meson setup \
--prefix /d/Repos/mediasoup/worker/out/Release \
--bindir '' \
--libdir '' \
--buildtype release \
-Db_ndebug=true \
-Db_pie=true \
-Db_staticpic=true \
--vsenv \
/d/Repos/mediasoup/worker/out/Release/build
The Meson build system
Version: 0.61.1
Source dir: D:\Repos\mediasoup\worker
Build dir: D:\Repos\mediasoup\worker\out\Release\build
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"
A full log can be found at D:\Repos\mediasoup\worker\out\Release\build\meson-logs\meson-log.txt
Directory already configured.
Just run your build command (e.g. ninja) and Meson will regenerate as necessary.
If ninja fails, run "ninja reconfigure" or "meson --reconfigure"
to force Meson to regenerate.
If build failures persist, run "meson setup --wipe" to rebuild from scratch
using the same options as passed when configuring the build.
To change option values, run "meson configure" instead.
/d/Repos/mediasoup/worker/scripts/cpu_cores.sh: line 9: nproc: command not found
/d/Repos/mediasoup/worker/out/pip/bin/meson compile -C /d/Repos/mediasoup/worker/out/Release/build -j 4 mediasoup-workerninja: Entering directory `D:/Repos/mediasoup/worker/out/Release/build'
[1/658] Compiling C object subprojects/libuv-v1.43.0/libuv.a.p/src_fs-poll.c.obj
FAILED: subprojects/libuv-v1.43.0/libuv.a.p/src_fs-poll.c.obj
"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_fs-poll.c.obj -MF "subprojects\libuv-v1.43.0\libuv.a.p\src_fs-poll.c.obj.d" -o subprojects/libuv-v1.43.0/libuv.a.p/src_fs-poll.c.obj "-c" ../../../subprojects/libuv-v1.43.0/src/fs-poll.c
CreateProcess failed: The system cannot find the file specified.
[2/658] Compiling C object subprojects/libuv-v1.43.0/libuv.a.p/src_random.c.obj
FAILED: subprojects/libuv-v1.43.0/libuv.a.p/src_random.c.obj
"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_random.c.obj -MF "subprojects\libuv-v1.43.0\libuv.a.p\src_random.c.obj.d" -o subprojects/libuv-v1.43.0/libuv.a.p/src_random.c.obj "-c" ../../../subprojects/libuv-v1.43.0/src/random.c
CreateProcess failed: The system cannot find the file specified.
[3/658] Compiling C object subprojects/libuv-v1.43.0/libuv.a.p/src_win_async.c.obj
FAILED: subprojects/libuv-v1.43.0/libuv.a.p/src_win_async.c.obj
"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.cCreateProcess failed: The system cannot find the file specified.
[4/658] Compiling C object subprojects/libuv-v1.43.0/libuv.a.p/src_win_core.c.obj
FAILED: subprojects/libuv-v1.43.0/libuv.a.p/src_win_core.c.obj
"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_core.c.obj -MF "subprojects\libuv-v1.43.0\libuv.a.p\src_win_core.c.obj.d" -o subprojects/libuv-v1.43.0/libuv.a.p/src_win_core.c.obj "-c" ../../../subprojects/libuv-v1.43.0/src/win/core.c
CreateProcess failed: The system cannot find the file specified.
ninja: build stopped: subcommand failed.
make: *** [mediasoup-worker] Error 1
make: Leaving directory `/d/Repos/mediasoup/worker'
npm ERR! code 1
npm ERR! path D:\Repos\mediasoup
npm ERR! command failed
npm ERR! command C:\Windows\system32\cmd.exe /d /s /c node npm-scripts.js postinstall
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\David\AppData\Local\npm-cache\_logs\2022-01-22T01_20_43_588Z-debug-0.log
Do you really need GCC? When installing MinGW, just choose msys-base and nothing else. This is enough for GNU make to work, and GCC will not mess with the compilation.
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']:
return False
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.
