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

Status: RESOLVED DUPLICATE of bug 1242724

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

Description

[Daniel Holbert [:dholbert]]

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

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 2

[Daniel Holbert [:dholbert]]

(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.

Comment 3

[u532768]

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

Comment 4

[Daniel Holbert [:dholbert]]

(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.)

Comment 5

[Mats Palmgren (inactive)]

Attachment: bandaid (this builds but breaks stuff)

Fwiw, this is the bandaid I'm currently using.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

This will probably be fixed by making it available always

Comment 7

[Daniel Holbert [:dholbert]]

(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.)

Comment 8

[u532768]

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.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

I have an r+ on bug 1242724 to fix this