error[E0432]: unresolved imports `backend::MidiInputPort`, `backend::MidiInput`, `backend::MidiInputConnection`, `backend::MidiOutputPort`, `backend::MidiOut`
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox95 | --- | unaffected |
firefox96 | --- | unaffected |
firefox97 | --- | fixed |
People
(Reporter: petr.sumbera, Assigned: gsvelto)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Steps to reproduce:
Solaris build fails with:
4:34.56 Compiling midir v0.7.0 (https://github.com/mozilla/midir.git?rev=dc87afbd4361ae5ec192e1fab0a6409dd13d4011#dc87afbd)
4:34.70 error[E0432]: unresolved imports `backend::MidiInputPort`, `backend::MidiInput`, `backend::MidiInputConnection`, `backend::MidiOutputPort`, `backend::MidiOut`
4:34.70 --> /builds/psumbera/mozilla-central-build/third_party/rust/midir/src/common.rs:5:5
4:34.70 |
4:34.70 5 | MidiInputPort as MidiInputPortImpl,
4:34.70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiInputPort` in `backend`
4:34.70 6 | MidiInput as MidiInputImpl,
4:34.70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiInput` in `backend`
4:34.70 7 | MidiInputConnection as MidiInputConnectionImpl,
4:34.70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiInputConnection` in `backend`
4:34.70 8 | MidiOutputPort as MidiOutputPortImpl,
4:34.70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiOutputPort` in `backend`
4:34.70 9 | MidiOutput as MidiOutputImpl,
4:34.70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiOutput` in `backend`
4:34.70 10 | MidiOutputConnection as MidiOutputConnectionImpl
4:34.70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `MidiOutputConnection` in `backend`
4:34.86 For more information about this error, try `rustc --explain E0432`.
4:34.88 error: could not compile `midir` due to previous error
The first bad revision is:
changeset: 602831:791abc86e799
user: Gabriele Svelto <gsvelto@mozilla.com>
date: Tue Dec 21 11:34:51 2021 +0000
description:
Bug 1728436 - Vendor the midir crate r=padenot
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Comment 2•3 years ago
|
||
Set release status flags based on info from the regressing bug 1728436
Comment 3•3 years ago
|
||
fwiw can confirm the build failure on OpenBSD where we use sndio. will try https://phabricator.services.mozilla.com/D134491
Comment 4•3 years ago
|
||
still fails with that patch, i have this in the build goo:
[15:29] c64:~/src/m-c/ $grep MOZ_WEBMIDI_MIDIR_BACKEND /usr/obj/m-c/*
/usr/obj/m-c/config.status: 'MOZ_WEBMIDI_MIDIR_BACKEND': '',
/usr/obj/m-c/config.status: 'MOZ_WEBMIDI_MIDIR_BACKEND': '',
/usr/obj/m-c/mozilla-config.h:#define MOZ_WEBMIDI_MIDIR_BACKEND
maybe it should be undef ?
Comment 5•3 years ago
|
||
should midir/midir_impl crates be made conditional to platforms in Cargo.lock file ? they shouldnt be built at all on non-supported platforms.. or there should be dummy/empty implementations for the missing symbols in the crates on non-tier1 ....
Assignee | ||
Comment 6•3 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #5)
should midir/midir_impl crates be made conditional to platforms in Cargo.lock file ? they shouldnt be built at all on non-supported platforms.. or there should be dummy/empty implementations for the missing symbols in the crates on non-tier1 ....
That should be conditional, I'll add the change to the patch.
Assignee | ||
Comment 7•3 years ago
|
||
The platform check should be fixed now but I haven't made building the midir crate conditional yet. Working on that now.
Updated•3 years ago
|
Assignee | ||
Comment 8•3 years ago
|
||
This should do the trick, can you please give the patch a spin and confirm that it's fixing your builds?
Comment 9•3 years ago
|
||
that gives
2:38.17 error: failed to load manifest for workspace member `/home/landry/src/m-c/toolkit/library/gtest/rust`
2:38.18 Caused by:
2:38.19 failed to load manifest for dependency `gkrust-shared`
2:38.19 Caused by:
2:38.19 failed to parse manifest at `/home/landry/src/m-c/toolkit/library/rust/shared/Cargo.toml`
2:38.19 Caused by:
2:38.19 feature `webmidi_midir_impl` includes `midir_impl` which is neither a dependency nor another feature
edit: same thing after a clobber/clean objdir
Assignee | ||
Comment 10•3 years ago
|
||
I had removed the reference to the crate and forgot to add it back. It should be working now.
Assignee | ||
Comment 11•3 years ago
|
||
The current patch should work but I can't test it directly, could you please give it a spin and see if it fixes the problem for you? If it does I'll land it right away.
Comment 12•3 years ago
|
||
i've readded the missing midir_impl = { path = "../../../../dom/midi/midir_impl", optional = true }
line to toolkit/library/rust/shared/Cargo.toml
(because, afaict that was the change added in the last revision of the diff) and the built of all cargo bits went fine.
libxul linking failed but i think this is for reasons totally unrelated to this issue:
79:20.94 ld: error: undefined hidden symbol: webrtc::kIsLibaomAv1EncoderSupported
79:20.94 >>> referenced by Unified_cpp_rnal_video_codecs_gn0.cpp
79:20.94 >>> /usr/obj/m-c/toolkit/library/build/../../../third_party/libwebrtc/media/rtc_internal_video_codecs_gn/Unified_cpp_rnal_video_codecs_gn0.o:(webrtc::InternalEncoderFactory::SupportedFormats())
79:20.94 >>> referenced by Unified_cpp_rnal_video_codecs_gn0.cpp
79:20.94 >>> /usr/obj/m-c/toolkit/library/build/../../../third_party/libwebrtc/media/rtc_internal_video_codecs_gn/Unified_cpp_rnal_video_codecs_gn0.o:(webrtc::InternalEncoderFactory::CreateVideoEncoder(webrtc::SdpVideoFormat const&))
79:20.94 ld: error: undefined hidden symbol: webrtc::CreateLibaomAv1Encoder()
79:20.95 >>> referenced by Unified_cpp_rnal_video_codecs_gn0.cpp
79:20.95 >>> /usr/obj/m-c/toolkit/library/build/../../../third_party/libwebrtc/media/rtc_internal_video_codecs_gn/Unified_cpp_rnal_video_codecs_gn0.o:(webrtc::InternalEncoderFactory::CreateVideoEncoder(webrtc::SdpVideoFormat const&))
wonder if this is something related to bug #1744644, :mjf any idea ?
Will clean my tree, pull from mozilla-central, reapply https://bugzilla.mozilla.org/attachment.cgi?id=9256512 and check my builds tomorrow.. but as far as your patch is concerned i think its good to go (eg the midir bits build failure seems solved), and thanks for handling that before 97 goes to beta.
Comment 13•3 years ago
|
||
:mjf, i think in bug #1744644 when you landed the json changes for https://hg.mozilla.org/integration/autoland/rev/724151aa470d and/or https://hg.mozilla.org/integration/autoland/rev/1c31dce53dff you didnt take OpenBSD into account, which could lead to the linking failure i'm seeing ? should that be a followup bug ?
Updated•3 years ago
|
Comment 14•3 years ago
|
||
I don't think those changes would have any OpenBSD dependencies since it is just officially turning off libaom for mozilla builds, which we were previously doing by commenting out code. However, if you generated the OpenBSD json and moz.build files before my changes landed in Bug 1744644, they would need to be regenerated to reflect the modifications in D133406 and D133407.
Comment 16•3 years ago
|
||
Comment 17•3 years ago
|
||
bugherder |
Description
•