842918 - SeaMonkey Windows builds are broken due to regression in disable-webRTC

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Edmund Wong (:ewong)]

Windows building with --disable-webRTC breaks with the following 
errors:


WMFUtils.obj : error LNK2001: unresolved external symbol _CLSID_CMP3DecMediaObject

WMFUtils.obj : error LNK2001: unresolved external symbol _CLSID_CMSH264DecoderMFT

xul.dll : fatal error LNK1120: 2 unresolved externals

Comment 1

[Edmund Wong (:ewong)]

Attachment: Disable webRTC on MacOSX only. (v1)

Comment 2

[Edmund Wong (:ewong)]

Pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/945662d34d67

Comment 3

[Justin Wood (:Callek)]

Comment on attachment 715892 [details] [diff] [review]
Disable webRTC on MacOSX only. (v1)

Review of attachment 715892 [details] [diff] [review]:
-----------------------------------------------------------------

As far as I know, this was fixed upstream. Lets back this out (once we are sure we have green first, so we can sanity check).

Comment 4

[Edmund Wong (:ewong)]

(In reply to Justin Wood (:Callek) from comment #3)
> Comment on attachment 715892 [details] [diff] [review]
> Disable webRTC on MacOSX only. (v1)
> 
> Review of attachment 715892 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> As far as I know, this was fixed upstream. Lets back this out (once we are
> sure we have green first, so we can sanity check).

Patch has been backed out:
http://hg.mozilla.org/comm-central/rev/ae219d0a01c8

Comment 5

[Justin Wood (:Callek)]

mkato, cpearce, 

So apparantly the patch in 839031 wasn't enough to fix this (our backout caused us to burn in exactly the same way again).

Can we work to figure out a proper fix? -- Remember this issue exists on aurora as well, where right now we have no WebRTC coverage due to this bug.

Comment 6

[Justin Wood (:Callek)]

...:

symbols.def : error LNK2001: unresolved external symbol vpx_codec_vp8_cx

NEXT ERROR gkmedias.lib : fatal error LNK1120: 1 unresolved externals

Comment 7

[Justin Wood (:Callek)]

(In reply to Justin Wood (:Callek) from comment #5)
> where right now we have no WebRTC coverage due to this bug.

I should wake up before typing in bugs... right now we have inconsistent WebRTC coverage across platforms due to this bug (we have WebRTC off on mac due to one bug, and on on Windows due to this one, we'd much prefer to have a consistent story regarding our web-features)

Comment 8

[Philip Chee]

Appears to be a regression from Bug 799069 (Unresolved vpx_codec_vp8_cx export in --disable-webrtc build)

http://hg.mozilla.org/mozilla-central/annotate/c233837cce08/layout/media/symbols.def.in#l43

43 #ifdef MOZ_VP8_ENCODER
44 vpx_codec_vp8_cx
45 #endif

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

What Philip Chee said. The Windows Media Foundation video backend doesn't use vpx_codec_vp8_cx, this must be bustage in --disable-webrtc somehow.

Comment 10

[Makoto Kato [:m_kato]]

WebRTC uses vpx_codec_vp8_cx in media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc.  Why MOZ_VP8_ENCODER=1 with --disable-webrtc?

Comment 11

[Justin Wood (:Callek)]

(In reply to Makoto Kato from comment #10)
> WebRTC uses vpx_codec_vp8_cx in
> media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc.  Why
> MOZ_VP8_ENCODER=1 with --disable-webrtc?

We're not setting MOZ_VP8_ENCODER=1, the issue is the (non seamonkey) code is wrongly doing this.

Comment 12

[Justin Wood (:Callek)]

(In reply to Justin Wood (:Callek) from comment #11)
> (In reply to Makoto Kato from comment #10)
> > WebRTC uses vpx_codec_vp8_cx in
> > media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc.  Why
> > MOZ_VP8_ENCODER=1 with --disable-webrtc?
> 
> We're not setting MOZ_VP8_ENCODER=1, the issue is the (non seamonkey) code
> is wrongly doing this.

To prove this, I'm pushing said WebRTC disabling for Firefox to try right now, for a windows only build, We should expect this same error to appear:

https://tbpl.mozilla.org/?tree=Try&rev=b6967106243c

Comment 13

[Justin Wood (:Callek)]

Hrm, using my releng-access I can see the Firefox build is beyond the point of the issue, and I also now see a newer SeaMonkey build that built gkmedias.dll properly. I actually now suspect the issue here was clobber-needed. :/ (even though I thought I clobbered)

ewong has a push to c-c try for doing this patch for TB, where if its green we'll resolve this bug. Sorry for the churn guys.

Comment 14

[Mozilla RelEng Bot]

Try run for b6967106243c is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=b6967106243c
Results (out of 1 total builds):
    success: 1
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b6967106243c

Comment 15

[Makoto Kato [:m_kato]]

Does symbols.def need dependency of $(GLOBAL_DEPS) if resolved by clobber?

Comment 16

[Makoto Kato [:m_kato]]

Attachment: fix to update symbol.def correctly

Comment 17

[Makoto Kato [:m_kato]]

landed for symbols.def to m-i.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5df355dff81c

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5df355dff81c