mediasoup-sys Build Error: "Subproject exists but has no meson.build file"
Bug Report
Operating system: macOS 14.3 (Darwin 24.3.0) Node version: N/A (Using Rust implementation) npm version: N/A (Using Rust implementation) gcc/clang version: Apple clang version 16.0.0 (clang-1600.0.26.6) mediasoup version: 0.17.1 (Rust crate) mediasoup-client version: N/A (Using Rust implementation)
Issue description
When building a Rust project that depends on the mediasoup crate (v0.17.1), the build fails with the following error:
meson.build:227:19: ERROR: Subproject exists but has no meson.build file.
This occurs during the compilation of the mediasoup-sys v0.9.1 dependency. The issue is that the flatbuffers subproject is missing its meson.build file, which should have been added by a patch from wrapdb.mesonbuild.com. The build process downloads the flatbuffers source code correctly, but fails to apply the patch that would add the necessary meson.build file. I was able to fix this issue by manually downloading and applying the patch:
- Navigate to the mediasoup-sys directory in the Cargo registry:
cd ~/.cargo/registry/src/index.crates.io-*/mediasoup-sys-0.9.1/subprojects
- Download the patch:
curl -L https://wrapdb.mesonbuild.com/v2/flatbuffers_24.3.6-1/get_patch -o flatbuffers_patch.zip
- Extract and apply the patch:
unzip -o flatbuffers_patch.zip -d flatbuffers-24.3.6
mv flatbuffers-24.3.6/flatbuffers-24.3.6/meson.build flatbuffers-24.3.6/
mv flatbuffers-24.3.6/flatbuffers-24.3.6/LICENSE.build flatbuffers-24.3.6/
rmdir flatbuffers-24.3.6/flatbuffers-24.3.6
After applying these steps, the build succeeds. This suggests that there might be an issue with how the mediasoup-sys crate handles the flatbuffers.wrap file or how the Meson build system applies patches from wrapdb. This issue affects anyone trying to use the Rust implementation of mediasoup on macOS, and possibly other platforms as well.
Please run "invoke (or make) clean-all" in worker/ folder and try again.
Note: I am closing the ticket because I am pretty sure it's that.
Ok reopening because I maybe wrong. @nazar-pc any thoughts?
Does it build if you clone the repo? It clearly compiles fine in CI, so I'm wondering what it could be.
When this happens, I typically run cargo clean on the project and if that doesn't work, I blow away my cargo registry cache rm -r ~/.cargo/registry/. You can also find the specific folder mediasoup-sys is in, but it's faster to just rm the whole path. That tends to fix it for me.
It seems to happen when multiple things try to compile mediasoup-sys at the same time (like if I have two projects open in vscode that both depend on mediasoup, and rust-analyzer does a build on both of them). This is actually one of my main drivers for opening #1498; to reduce the places where that build is occurring in my workspace.
Interesting, I guess we can try to add a lock to make sure two things are not competing with each other. Though the whole thing sounds like Meson issue. I don't like that it writes stuff into subprojects directory instead of build target directory, which messes up ~/.cargo/registry (which should never be written to by the build scripts).
Another alternative would be to copy stuff from there to build output before running Meson, but that feels wrong too.
Can we close this ticket? Is there something actionable from our side? I don't want to keep this ticket open forever without real activity or real work on it.
I guess it'd be nice if upstream modified Meson behavior, we could then take advantage of it here.
Until then we could still work around it if there is enough demand with additional checks in the code, though so far it was not happening very often.
I seem to be having the same problem using the rust package operating system:windows Development Language: rust Version: 0.19.0 Found ninja.exe-1.10.2.git.kitware.jobserver-1 at D:/programCode/rust/webrtc/webrtc/target/debug/build/mediasoup-sys-a182db445651bb97/out/out/pip_meson_ninja/bin/ninja.exe
Visual Studio environment is needed to run Ninja. It is recommended to use Meson wrapper: D:\programCode\rust\webrtc\webrtc\target\debug\build\mediasoup-sys-a182db445651bb97\out\out\pip_meson_ninja\bin\meson compile -C D:\programCode\rust\webrtc\webrtc\target\debug\build\mediasoup-sys-a182db445651bb97\out\build
ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
D:\programCode\rust\webrtc\webrtc> D:\programCode\rust\webrtc\webrtc\target\debug\build\mediasoup-sys-a182db445651bb97\out\out\pip_meson_ninja\bin\meson compile -C D:\programCode\rust\webrtc\webrtc\target\debug\build\mediasoup-sys-a182db445651bb97\out\build
ERROR: Current directory is not a meson build directory: D:\programCode\rust\webrtc\webrtc\target\debug\build\mediasoup-sys-a182db445651bb97\out\build.
Please specify a valid build dir or change the working directory to it.
It is also possible that the build directory was generated with an old
meson version. Please regenerate it in this case.
You can try deleting D:\programCode\rust\webrtc\webrtc\target\debug\build\mediasoup-sys-a182db445651bb97\out and see if it helps.
What did you do before you got that error? That is the most important question. If we can reproduce it reliably, we'll be able to verify the fix.
You can try deleting
D:\programCode\rust\webrtc\webrtc\target\debug\build\mediasoup-sys-a182db445651bb97\outand see if it helps.What did you do before you got that error? That is the most important question. If we can reproduce it reliably, we'll be able to verify the fix.
I also tried cargo clean and then build and the same problem still occurred. I also tried deleting the target directory.
What did you do before you got that error? That is the most important question. If we can reproduce it reliably, we'll be able to verify the fix.
@wxj127 can you answer this question please?
It could also be Cargo's registry cache directory instead of target where it downloads crates
This error report is more detailed :
mediasoup-worker undefined
Subprojects
abseil-cpp : YES
catch2 : YES
flatbuffers: YES
libsrtp3 : YES
libuv : YES
openssl : YES 1 warnings
usrsctp : YES
wingetopt : YES
User defined options
bindir : \
buildtype : release
libdir : \
prefix : D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out
vsenv : true
b_ndebug : true
Found ninja-1.10.2.git.kitware.jobserver-1 at D:\soft\miniconda3\Scripts\ninja.EXE
Visual Studio environment is needed to run Ninja. It is recommended to use Meson wrapper:
D:\programCode\rust\Media-server\server\target\debug\build\mediasoup-sys-ca35bc759754d56f\out\out\pip_meson_ninja\bin\meson compile -C D:\programCode\rust\Media-server\server\target\debug\build\mediasoup-sys-ca35bc759754d56f\out\build
Traceback (most recent call last):
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\mesonmain.py", line 188, in run
return options.run_func(options)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\msetup.py", line 364, in run
app.generate()
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\msetup.py", line 187, in generate
return self._generate(env, capture, vslite_ctx)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\msetup.py", line 252, in _generate
captured_compile_args = intr.backend.generate(capture, vslite_ctx)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\backend\ninjabackend.py", line 674, in generate
self.generate_ending()
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\backend\ninjabackend.py", line 3741, in generate_ending
deps = self.get_regen_filelist()
^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\backend\backends.py", line 1351, in get_regen_filelist
self.check_clock_skew(deps)
File "D:\soft\miniconda3\Lib\site-packages\mesonbuild\backend\backends.py", line 1372, in check_clock_skew
ftime = os.path.getmtime(absf)
^^^^^^^^^^^^^^^^^^^^^^
File "
ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
The original window path is too long and exceeds use Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 success
But there's another problem. mediasoup-worker undefined Subprojects abseil-cpp : YES catch2 : YES flatbuffers: YES libsrtp3 : YES libuv : YES openssl : YES 1 warnings usrsctp : YES wingetopt : YES
User defined options
bindir :
buildtype : release
libdir :
prefix : D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out
vsenv : True
b_ndebug : true
Found ninja.exe-1.10.2.git.kitware.jobserver-1 at D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out/out/pip_meson_ninja/bin/ninja.exe
Visual Studio environment is needed to run Ninja. It is recommended to use Meson wrapper: D:\programCode\rust\Media-server\server\target\debug\build\mediasoup-sys-ca35bc759754d56f\out\out\pip_meson_ninja\bin\meson compile -C . Cleaning... 0 files. INFO: autodetecting backend as ninja INFO: calculating backend command to run: D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out/out/pip_meson_ninja/bin/ninja.exe -C D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out/build fbs\FBS
The last error means MSVC is probably not configured properly. There were discussions about this on the forum, try to use search there. I don't believe it is a but in mediasoup and it works fine in CI where MSVC is configured as it should be.
The last error means MSVC is probably not configured properly. There were discussions about this on the forum, try to use search there. I don't believe it is a but in mediasoup and it works fine in CI where MSVC is configured as it should be.
I have installed the MSVC environment , Execution cmd D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out/out/pip_meson_ninja/bin/ninja.exe -C D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out/build fbs\FBS
mediasoup-worker undefined Subprojects abseil-cpp : YES catch2 : YES flatbuffers: YES libsrtp3 : YES libuv : YES openssl : YES 1 warnings usrsctp : YES wingetopt : YES User defined options bindir : buildtype : release libdir : prefix : D:/programCode/rust/Media-server/server/target/debug/build/mediasoup-sys-ca35bc759754d56f/out vsenv : True b_ndebug : true Found ninja-1.10.2.git.kitware.jobserver-1 at D:\soft\miniconda3\Scripts\ninja.EXE Visual Studio environment is needed to run Ninja. It is recommended to use Meson wrapper: D:\programCode\rust\Media-server\server\target\debug\build\mediasoup-sys-ca35bc759754d56f\out\out\pip_meson_ninja\bin\meson compile -C . Cleaning... 0 files. [0/1] Regenerating build files.
Then it loops infinitely...
Node version likely doesn't actually build anything since recent versions use pre-built binaries by default (see "Assets" under each release), while Rust version compiles C++ code into your application statically. Naturally, the first case doesn't need C++ toolchain at all, while for second it is mandatory.
Node version likely doesn't actually build anything since recent versions use pre-built binaries by default (see "Assets" under each release), while Rust version compiles C++ code into your application statically. Naturally, the first case doesn't need C++ toolchain at all, while for second it is mandatory.
This I know, the trust needs to use the source code build, but I encountered https://mediasoup.discourse.group/t/mediasoup-library-in-rust/1803/54 ; The same problem, which I don't know how to solve...
Hi, guys. Maybe I'm wrong but this bug report is no longer about something specific but instead it's becoming a collection of different problems when building a mediasoup based Rust app. If that, it must be moved to the support forum. This ticket in GitHub was supposed to be exclusively about the original reported problem:
mediasoup-sys Build Error: "Subproject exists but has no meson.build file"
Is it about it? Or that problem was solved somehow so we are iterating into next ongoing problems?
This occurs during the compilation of the mediasoup-sys v0.9.1 dependency. The issue is that the flatbuffers subproject is missing its meson.build file, which should have been added by a patch from wrapdb.mesonbuild.com. The build process downloads the flatbuffers source code correctly, but fails to apply the patch that would add the necessary meson.build file.
How can this happen? When installing mediasoup in Node (with MEDIASOUP_SKIP_WORKER_PREBUILT_DOWNLOAD=true to avoid that it fetches a prebuilt worker binary) the resulting node_modules/mediasoup/worker/subprojects/flatbuffers-24.3.25/ folder contains a meson.build file. How is it possible that such a file doesn't exist when installing mediasoup-sys crate?
@mattmillen888 can you provide a simple Rust app and steps to reproduce the problem?
I've created a simple Rust app with this Cargo.toml:
[package]
name = "mediasoup-rust-app"
version = "0.1.0"
edition = "2024"
[dependencies]
mediasoup = "0.17.1"
Then I run cargo build (in macOS 15.6.1). It failed with a completely unrelated error:
error[E0004]: non-exhaustive patterns: `mediasoup_sys::fbs::rtp_parameters::RtpHeaderExtensionUri::DependencyDescriptor` not covered
--> /Users/ibc/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/mediasoup-0.17.1/src/rtp_parameters.rs:635:15
|
635 | match uri {
| ^^^ pattern `mediasoup_sys::fbs::rtp_parameters::RtpHeaderExtensionUri::DependencyDescriptor` not covered
|
note: `mediasoup_sys::fbs::rtp_parameters::RtpHeaderExtensionUri` defined here
--> /private/tmp/kk/mediasoup-rust-app/target/debug/build/mediasoup-sys-1df58a00b1b6f47d/out/fbs.rs:46404:13
|
46404 | pub enum RtpHeaderExtensionUri {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
46442 | DependencyDescriptor = 12,
| -------------------- not covered
= note: the matched value is of type `mediasoup_sys::fbs::rtp_parameters::RtpHeaderExtensionUri`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
|
665 ~ },
666 + mediasoup_sys::fbs::rtp_parameters::RtpHeaderExtensionUri::DependencyDescriptor => todo!()
|
For more information about this error, try `rustc --explain E0004`.
Such a error doesn't happen with latest mediasoup crate 0.20.0. Everything is good using it.
I'm closing this issue. If I missed something in my attempt to reproduce the issue, please comment it.