Open Bug 1393901 Opened 7 years ago Updated 11 months ago

--enable-webrtc does not build under MinGW

Categories

(Core :: WebRTC, enhancement, P5)

Product:
Core
Component:
WebRTC
Type:
enhancement

Tracking

()

People

(Reporter: tjr, Assigned: tjr)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor])

Attachments

(4 files)

Bug 1393901 Enable WebRTC for the MinGW build
59 bytes, text/x-review-board-request
Details
Bug 1393901: Local OS_LIBS capitalization fixes r?dminor
48 bytes, text/x-phabricator-request
Details | Review
WIP: Bug 1393901: Upstream capitalization fixes
48 bytes, text/x-phabricator-request
Details | Review
WIP: Bug 1393901: WIP!!! Everything else
48 bytes, text/x-phabricator-request
Details | Review 
This is a tracking bug
Rank: 25
Priority: -- → P2
Rank: 25 → 45
Priority: P2 → P4
Mass change P4->P5 to align with new Mozilla triage process.
Priority: P4 → P5
Depends on: 1460631

Alex from Waterfox was able to get WebRTC building under mingw-clang. I've reproduced it locally. He reported "Unfortunately it appears networking itself doesn't work - but microphone, webcam do."

I'd like to try and get his patches landed even if the functionality needs debugging, so we don't regress on this awesome achievement.

Presently there are two components here: one is a set of patches to Firefox; and the second is a set of patches to mingw/clang. The latter set of patches are more workarounds that need a better solution, so I'll be exploring that.

Dan are you the best person to provide (initial) review/guidance on these patches? I'd like to land the first (OS_LIBS) one now; and I'd like your feedback on the second one fixing capitalization upstream. Where would I submit that patch upstream and what would be the process? (And how would I land fixes in the mozilla tree such that landing it upstream doesn't cause a problem when we want to update?)

Flags: needinfo?(dminor)

I'm not working on WebRTC right now, I think Nico would be the best person to help you with this, he's currently leading a libwebrtc update project.

Flags: needinfo?(dminor) → needinfo?(na-g)

Progress update: I've refactored all the compiler changes out into Firefox changes and have a working x64 build. Continuing cleanup and will work on x86 also.

Tom, the moz.build files under libwebrtc should not be manually edited. There are accompanying BUILD.gn files that need to be changed and then the moz.build files need to be regenerated. It is best to use two different patches, one for the BUILD.gn fixes and one for the moz.build regenerations. We are in the middle of the next libwebrtc merge-in, Bug 1654112, and have developed a script to make that process easier for us, it may not work on moz-central but it should give you a good idea of what needs to be done. Check the README.md file for details, https://hg.mozilla.org/users/na-g_nostrum.com/libwebrtc-merge-2H2020/file/tip/dom/media/webrtc/third_party_build/gn-configs . You can also try your changes on the libwebrtc merge branch. I will note that the Strmiids.h -> strmiids.h issue seems to already be fixed in the version that we have vendored into the merge branch.

Some digging in the upstream repository revealed the following patch https://webrtc-review.googlesource.com/c/src/+/64762/ for lower casing the library names on Windows.

Flags: needinfo?(na-g)

@tjr @Tom Ritter, I dont see any dependent issue for compiling webrtc under MinGW, But the issue left for 6 months without any update. Is anyone working on this ? Any update ?

Indeed, I think the last time I had time to work on it was before Christmas. I have to page it back into my mind; but my last status was working on upstreaming some MinGW changes that were needed for this. (Either for this directly, or to fix the build a different MinGW update broke so we could bump MinGW to get the updates for this - can't quite remember.)

I want to/intend to get back to it, but I don't have any ETA. If someone wants to contribute I'd be happy to mentor, but it's not a good introductory project for someone brand new.

Severity: normal → S3

We have a few commits to make WebRTC buildable with mingw for ESR 102 downstream at Tor Browser:

I have managed to port them to nightly, a couple of weeks ago, but I seem not to have that local branch anymore.
However, they are almost conflict-free, except for a conflict in the various #undef, and the conflict in a .cc file of libwebrtc (the one where we changed int with pid_t).

Here you can find the squashed and rebased commits: https://hg.mozilla.org/try/rev/e94574f3ed49626f56fdd8a562f61ecc2e8d3830.
Please, notice that you need to change pid_ with mPid here, if you take it:

void DesktopDisplayDevice::setPid(const pid_t pid) { pid_ = pid; }

That was the cause of the failure of my try build, but I did not try it again.

(In reply to Pier Angelo Vendrame from comment #13)

We have a few commits to make WebRTC buildable with mingw for ESR 102 downstream at Tor Browser:

I have managed to port them to nightly, a couple of weeks ago, but I seem not to have that local branch anymore.
However, they are almost conflict-free, except for a conflict in the various #undef, and the conflict in a .cc file of libwebrtc (the one where we changed int with pid_t).

Here you can find the squashed and rebased commits: https://hg.mozilla.org/try/rev/e94574f3ed49626f56fdd8a562f61ecc2e8d3830.
Please, notice that you need to change pid_ with mPid here, if you take it:

void DesktopDisplayDevice::setPid(const pid_t pid) { pid_ = pid; }

That was the cause of the failure of my try build, but I did not try it again.

Does WebRTC work now with the changes made to WebRTC since 2020, when built with mingw?

(In reply to Alex Kontos from comment #14)

Does WebRTC work now with the changes made to WebRTC since 2020, when built with mingw?

It works for us in our 102.x fork, with the network process disabled, but we have not checked the latest nightly, yet.
I expect it to work pretty easily, once it builds.

Tom, I've just got a working try build: https://treeherder.mozilla.org/jobs?repo=try&revision=6ff31d8f626162f73f416cc48109f9bb0f5e3545.
Probably the conversion from TCHAR to char could be improved.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: