1447070 - build failure in dom/media/eme in non-unified builds: "MediaKeySession.h:31:39: error: expected constructor, destructor, or type conversion before ‘;’ token"

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Daniel Holbert [:dholbert]]

If I drop "UNIFIED_" from dom/media/eme/moz.build, I get this build failure:
========
In file included from ../../../../mozilla/dom/media/eme/MediaKeySystemAccess.cpp:9:0:
../../../dist/include/mozilla/dom/MediaKeySession.h:31:39: error: expected constructor, destructor, or type conversion before ‘;’ token
 DDLoggedTypeName(dom::MediaKeySession);
                                       ^
../../../dist/include/mozilla/dom/MediaKeySession.h:47:35: error: expected template-name before ‘<’ token
   , public DecoderDoctorLifeLogger<MediaKeySession>
                                   ^
../../../dist/include/mozilla/dom/MediaKeySession.h:47:35: error: expected ‘{’ before ‘<’ token
../../../dist/include/mozilla/dom/MediaKeySession.h:47:35: error: expected unqualified-id before ‘<’ token
========

We're missing the definition for DecoderDoctorLifeLogger there. We just need to #include "DecoderDoctorLogger.h". With that, this directory builds fine with unification disabled.

(Per firefox-dev mailing list post from today: Apparently some people are hitting this build bustage even with unification disabled, perhaps due to having a different configuration which triggers slightly different file grouping, which loses us the #include-in-some-other-file that we're inadvertently depending on right now.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: Bug 1447070: Give MediaKeySession.h the #include it needs to provide 'DecoderDoctorLifeLogger' type (to fix non-unified build error).

Review commit: https://reviewboard.mozilla.org/r/229028/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/229028/

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)
> (Per firefox-dev mailing list post from today: Apparently some people are
> hitting this build bustage even with unification disabled, perhaps due to
> having a different configuration which triggers slightly different file
> grouping, which loses us the #include-in-some-other-file that we're
> inadvertently depending on right now.)

Specifically: this post was from cgrobertson, who's hitting this build error when compiling "obj/dom/bindings/UnifiedBindings21.cpp" for 32-bit Firefox. (Presumably we get slightly different unification in that subdirectory on his platform).  CC'd him.  (Charles, please let us know if this is for an official Suse package or something like that, vs. just for your own local build. If it's for an official package used by lots of people, then maybe we'd want to convince release managers to take this patch as an uplift to the Firefox 59 source tree -- not to spin up a dot release, but just to get it building for folks who haven't been able to build it yet.)

Comment 3

[Daniel Holbert [:dholbert]]

(Or alternately, rather than uplifting, this might just be a patch that Charles would use use as a spot-fix for the build error when compiling the package. I'm not a lawyer & I don't know about the mechanics or legalistic trademark stuff around local changes for specific distributions of Firefox, but I imagine this sort of fix would be sort of thing that would be fine as a spot-fix on the distribution side.)

Comment 4

[Gerald Squelart [:gerald] (he/him)]

Comment on attachment 8960266 [details]
Bug 1447070: Give MediaKeySession.h the #include it needs to provide 'DecoderDoctorLifeLogger' type (to fix non-unified build error).

https://reviewboard.mozilla.org/r/229028/#review234850

Thank you.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e56f781dbaf9
Give MediaKeySession.h the #include it needs to provide 'DecoderDoctorLifeLogger' type (to fix non-unified build error). r=gerald

Comment 6

[Charles Robertson]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> (In reply to Daniel Holbert [:dholbert] from comment #0)
> > (Per firefox-dev mailing list post from today: Apparently some people are
> > hitting this build bustage even with unification disabled, perhaps due to
> > having a different configuration which triggers slightly different file
> > grouping, which loses us the #include-in-some-other-file that we're
> > inadvertently depending on right now.)
> 
> Specifically: this post was from cgrobertson, who's hitting this build error
> when compiling "obj/dom/bindings/UnifiedBindings21.cpp" for 32-bit Firefox.
> (Presumably we get slightly different unification in that subdirectory on
> his platform).  CC'd him.  (Charles, please let us know if this is for an
> official Suse package or something like that, vs. just for your own local
> build. If it's for an official package used by lots of people, then maybe
> we'd want to convince release managers to take this patch as an uplift to
> the Firefox 59 source tree -- not to spin up a dot release, but just to get
> it building for folks who haven't been able to build it yet.)

Thank you for getting back on this so quickly. Yes, this is for an official SUSE release. I am trying out your fix and will let you know how it goes. Thanks again.

Comment 7

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/e56f781dbaf9

Comment 8

[Charles Robertson]

Including the "DecoderDoctorLogger.h" header file did not completely fix the problem. The build fails now with one error:

In file included from /home/abuild/rpmbuild/BUILD/obj/dom/bindings/UnifiedBindings45.cpp:14:0:
/home/abuild/rpmbuild/BUILD/obj/dom/bindings/WorkerGlobalScopeBinding.cpp:1560:34: error: 'mozilla::dom::DOMPrefs' has not been declared
true, false, 0, &mozilla::dom::DOMPrefs::DOMCachesEnabled
                               ^~~~~~~~
With WorkerGlobalScopeBinding.cpp being an autogenerated file I have no idea how to fix this. This may be totally unrelated to the previous problem but obviously dependent on some 32bit build setting.

Can you please advise?

Comment 9

[Daniel Holbert [:dholbert]]

I spun off comment 8's issue as bug 1447409, with a suggested workaround in bug 1447409 comment 3.