Closed Bug 1242719 Opened 9 years ago Closed 9 years ago

dom/network/UDPSocketParent.cpp:24:10: fatal error: 'mtransport/runnable_utils.h' file not found

Categories

(Core :: WebRTC: Networking, defect, P1)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1242724

People

(Reporter: dholbert, Assigned: jesup)

References

Details

Attachments

(1 file)

My --disable-webrtc build currently fails with:
{
> dom/network/UDPSocketParent.cpp:24:10: fatal error: 'mtransport/runnable_utils.h' file not found
> #include "mtransport/runnable_utils.h"
>          ^
> 1 error generated.
}

This #include was just recently added here, as part of bug 1194259:
https://hg.mozilla.org/mozilla-central/rev/5c372359d5ba#l5.2
Flags: needinfo?(rjesup)
We need to publish that runnable_utils.h file and associated code always, not just if webrtc is enabled, and eventually either move it to mfbt/etc or replace it.

We could ifdef stuff we added to UDPSocket on webrtc, though that seems silly.
Flags: needinfo?(rjesup)
Depends on: 1242724
(In reply to Randell Jesup [:jesup] from comment #1)
> We need to publish that runnable_utils.h file and associated code always,
> not just if webrtc is enabled

I've now filed bug 1242724 on doing specifically that, FWIW. (Feel free/encouraged to take it! :))

I marked this bug as depending on that bug.
Thanks.  I was just going to post a compiler error for this very thing in today's (20160125) nightly.  And I have webRTC disabled in my .mozconfig.

UDPSocketParent.cpp:24:39: fatal error: mtransport/runnable_utils.h: No such file or directory
(If this is blocking you from building, the easiest workaround is to just build with webrtc enabled. If you can't do that for some reason, then you may want to try to come up with a local hackaround/bandaid patch like the one in bug 1241628.)
Fwiw, this is the bandaid I'm currently using.
This will probably be fixed by making it available always
Assignee: nobody → rjesup
backlog: --- → webrtc/webaudio+
Rank: 15
Priority: -- → P1
(In reply to Randell Jesup [:jesup] from comment #6)
> This will probably be fixed by making it available always

(I was imagining that we (er, you! :)) would do this on helper-bug 1242724, as an abstract clean place to do the refactoring -- and then that'd end up fixing the bustage on this bug here & bug 1241628 "for free" as dependencies. But, if you'd prefer to just fix this here & dupe bug 1241628 to this, that works too.)
Thanks for the suggestions.  It's not urgent that I get the latest and greatest nightly working.  I still have the nightly from last thursday, so I'm not way out of date.  And I also have the production firefox from the distro I run as well.  This happens occasionally, and then it gets fixed.

I can live with webrtc, if I need to enable it to get a compile to work.  I just like to keep the browser as lean as possible so that I don't load functionality I'm not using, and so that I minimize attack surface.
I have an r+ on bug 1242724 to fix this
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: