Closed Bug 1313560 Opened 3 years ago Closed 3 years ago
_cpp _layout _generic2 .obj : error LNK2019: unresolved external symbol "public: enum nsresult __cdecl img Loader::Load Image W(class ns IURI *,class ns IURI *,class ns IURI *,enum mozilla::net::Referrer Policy,class ns IPrincipal *,class ns ILoad Group *,class
Inbound Win8 builds are red right now, with this error: ======== Unified_cpp_layout_generic2.obj : error LNK2019: unresolved external symbol "public: enum nsresult __cdecl imgLoader::LoadImageW(class nsIURI *,class nsIURI *,class nsIURI *,enum mozilla::net::ReferrerPolicy,class nsIPrincipal *,class nsILoadGroup *,class imgINotificationObserver *,class nsINode *,class nsIDocument *,unsigned int,class nsISupports *,unsigned int,class nsAString_internal const &,class imgRequestProxy * *)" (?LoadImageW@imgLoader@@QEAA?AW4nsresult@@PEAVnsIURI@@00W4ReferrerPolicy@net@mozilla@@PEAVnsIPrincipal@@PEAVnsILoadGroup@@PEAVimgINotificationObserver@@PEAVnsINode@@PEAVnsIDocument@@IPEAVnsISupports@@IAEBVnsAString_internal@@PEAPEAVimgRequestProxy@@@Z) referenced in function "private: enum nsresult __cdecl nsImageFrame::LoadIcon(class nsAString_internal const &,class nsPresContext *,class imgRequestProxy * *)" (?LoadIcon@nsImageFrame@@AEAA?AW4nsresult@@AEBVnsAString_internal@@PEAVnsPresContext@@PEAPEAVimgRequestProxy@@@Z) ======== https://treeherder.mozilla.org/logviewer.html#?job_id=38336180&repo=mozilla-inbound#L18801 dmajor says this is likely due to windows.h doing some stupid #define from LoadImage to LoadImageW, or something like that. I think this is unified-build bustage from an earlier push (maybe one of mine), which was unlucky enough to group nsImageFrame.cpp with another .cpp file that #includes windows.h.
This is based on https://dxr.mozilla.org/mozilla-central/source/dom/media/webspeech/recognition/SpeechRecognition.cpp#37
Attachment #8805422 - Flags: review?(dmajor)
(In reply to Daniel Holbert [:dholbert] from comment #0) > Inbound Win8 builds are red right now, with this error: This is causing WinXP bustage, too: https://treeherder.mozilla.org/logviewer.html#?job_id=38335459&repo=mozilla-inbound#L19478
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4f928f174d21 Undefine windows.h's LoadImage macro, to avoid bustage in nsImageFrame.cpp. r=dmajor
So, this didn't work, because imgLoader.h got pulled in before the #undef, so now the declaration is LoadImageW and the callsite is LoadImage. This could probably be fixed by stopping the damage earlier on, at https://dxr.mozilla.org/mozilla-central/source/layout/generic/nsPluginFrame.h#23 But now this is getting messy enough that I'd be reluctantly ok with de-unifying nsImageFrame.cpp at this point. :/
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/691c898f58a275dd965ad6bca4d93ea8f98c3996 for not actually working.
(In reply to David Major [:dmajor] from comment #4) > So, this didn't work, because imgLoader.h got pulled in before the #undef, > so now the declaration is LoadImageW and the callsite is LoadImage. > > This could probably be fixed by stopping the damage earlier on, at > https://dxr.mozilla.org/mozilla-central/source/layout/generic/nsPluginFrame.h#23 That does indeed fix this, locally (testing on Windows locally now, where I'm able to reproduce the build issue). I'll push a patch with the undef at that location, with rs=dmajor. Based on comment 4, I'm going to assume you're cool rubberstamping that change. :)
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/6abb6ebe96b7 Undefine LoadImage in nsPluginFrame.h (alongside other undefines) to prevent windows.h macros from causing unified bustage in other files. rs=dmajor
You need to log in before you can comment on or make changes to this bug.