xulrunner-stub builds broken on windows since June 5th

RESOLVED FIXED in Firefox 41

Status

defect
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: nthomas, Assigned: nthomas)

Tracking

Trunk
mozilla42
Dependency tree / graph

Firefox Tracking Flags

(firefox39 unaffected, firefox40 unaffected, firefox41 fixed, firefox42 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

xpcomglue_staticruntime.lib(pldhash.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) class mozilla::Atomic<unsigned int,2,void> mozilla::detail::gChaosModeCounter" (__imp_?gChaosModeCounter@detail@mozilla@@3V?$Atomic@I$01X@2@A)

xulrunner-stub.exe : fatal error LNK1120: 1 unresolved externals

(http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2015/06/2015-06-05-03-02-05-mozilla-central/mozilla-central-win32-xulrunner-nightly-bm85-build1-build4.txt.gz)

From something in this http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=98820360ab66&tochange=0496b5b3e9ef

[Tracking Requested - why for this release]:
I'm not sure if XULRunner is still a deliverable for releases, given dropping XPCOM with https://blog.mozilla.org/addons/2015/05/04/dropping-support-for-binary-components/. Tracking? just in case.
Blocks: 1164218
(In reply to Nick Thomas [:nthomas] from comment #0)
> I'm not sure if XULRunner is still a deliverable for releases, given
> dropping XPCOM with
> https://blog.mozilla.org/addons/2015/05/04/dropping-support-for-binary-
> components/. Tracking? just in case.

That's a good question. Benjamin, do we still care about the SDK given the above?
Flags: needinfo?(benjamin)
I think we still want the SDK. But there's no reason to continue Windows XULRunner builds: we have the SDK from the Firefox builds on Windows already.
Flags: needinfo?(benjamin)
Benjamin, as I don't fully understand the impact of this bug, but assuming no FF functionality is broken, I do not want to track this bug for FF41. Do you have any concerns with that? Please let me know if we still need to track it.
Flags: needinfo?(benjamin)
The functional requirement is that we still have an SDK package. I believe that requirement is satisfied by the Firefox build and that this bug doesn't need to block, but nthomas should confirm that.
Flags: needinfo?(benjamin)
Ben, how does this fit in with your plans for XULRunner ? This bug means we don't have any Windows runtimes for the 41 cycle. Also unknown SDK state given we do that later in the job than the runtime.
Flags: needinfo?(bhearsum)
(In reply to Benjamin Smedberg  [:bsmedberg] (away until 27-July) from comment #4)
> The functional requirement is that we still have an SDK package. I believe
> that requirement is satisfied by the Firefox build and that this bug doesn't
> need to block, but nthomas should confirm that.

We won't be generating the SDK with Firefox until 42. It's possible that we may be able to uplift that, but my previous blog post (http://hearsum.ca/blog/mozilla-will-stop-producing-automated-builds-of-xulrunner-after-the-410-cycle.html) more or less promises that the XULRunner SDK/stub will be available until 42, so it would be preferable to fix this bug IMO.
Flags: needinfo?(bhearsum)
Ok. It's not terribly convenient, from a release automation point of view, to be shipping the SDK out of Firefox builds out of an old code base (which would need to learn a new trick), plus some runtimes from the existing builds. It would be cleaner to cut over all platforms with Ben's work in the near future.

Is the problem with windows that the standalone xpcom needs to include mfbt when linking ?
glandium, do you have any thoughts about my (naive) guess in comment #7 ?
Flags: needinfo?(mh+mozilla)
FYI, I'm only interested in fixing this in aurora, so that it's working in beta after the merge next week (the jobs got killed in m-c already). The latest log is at http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2015-08-05-00-40-14-mozilla-aurora/mozilla-aurora-win32-xulrunner-nightly-bm84-build1-build2.txt.gz, search for 'xulrunner-stub.exe : fatal error LNK1120: 1 unresolved externals'.
Yeah, seems like adding USE_LIBS += ['mfbt_staticruntime'] on windows would "fix" it.
Flags: needinfo?(mh+mozilla)
Posted patch Add mfbt_staticruntime (obsolete) — Splinter Review
This compiles but there is a warning:

xulrunner-stub.exe
c:/builds/moz2_slave/m-aurora-w32-xr-ntly-000000000/build/obj-firefox/_virtualenv/Scripts/python.exe c:/builds/moz2_slave/m-aurora-w32-xr-ntly-000000000/build/config/expandlibs_exec.py --uselist -- link -NOLOGO -OUT:xulrunner-stub.exe -PDB:xulrunner-stub.pdb -ENTRY:wmainCRTStartup -SUBSYSTEM:WINDOWS,5.01 -LARGEADDRESSAWARE -NXCOMPAT -RELEASE -DYNAMICBASE -SAFESEH  -DEBUG -DEBUGTYPE:CV -DEBUG -OPT:REF     nsXULStub.obj ./module.res ../../xpcom/glue/standalone/staticruntime/xpcomglue_staticruntime.lib ../../memory/fallible/fallible.lib ../../mfbt/staticruntime/mfbt_staticruntime.lib   kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib secur32.lib netapi32.lib shell32.lib
   Creating library xulrunner-stub.lib and object xulrunner-stub.exp
xpcomglue_staticruntime.lib(pldhash.obj) : warning LNK4049: locally defined symbol ?gChaosModeCounter@detail@mozilla@@3V?$Atomic@I$01X@2@A (class mozilla::Atomic<unsigned int,2,void> mozilla::detail::gChaosModeCounter) imported

(I haven't been 100% careful to run this in the same environment as the regular builds)
Attachment #8644224 - Flags: review?(mh+mozilla)
Comment on attachment 8644224 [details] [diff] [review]
Add mfbt_staticruntime

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

::: xulrunner/stub/moz.build
@@ +28,5 @@
>  ]
>  
>  if CONFIG['OS_ARCH'] == 'WINNT':
>      LOCAL_INCLUDES += ['/toolkit/xre']
> +    USE_LIBS += ['mfbt_staticruntime']

Please add a comment that this is an awful workaround.
Attachment #8644224 - Flags: review?(mh+mozilla) → review+
With comment, carrying review.
Assignee: nobody → nthomas
Attachment #8644224 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8644695 - Flags: review+
Comment on attachment 8644695 [details] [diff] [review]
Add mfbt_staticruntime (with comment)

Approval Request Comment
[Feature/regressing bug #]: bug 1164218
[User impact if declined]: blocks xulrunner deliverables for 41 cycle on windows; some external parties use these to create apps based on gecko.
[Describe test coverage new/current, TreeHerder]: None, we're not building xulrunner on trunk any more (deprecated in 42)
[Risks and why]: Minimal, xulrunner could still be busted on windows
[String/UUID change made/needed]: None
Attachment #8644695 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/2ac09126d207
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Comment on attachment 8644695 [details] [diff] [review]
Add mfbt_staticruntime (with comment)

Switching approval request to beta, since we merged today. The fix was on central, and is now merged to aurora. We need it on beta for the xulrunner bits we ship for 41.0.
Attachment #8644695 - Flags: approval-mozilla-aurora? → approval-mozilla-beta?
Comment on attachment 8644695 [details] [diff] [review]
Add mfbt_staticruntime (with comment)

Approved. We need xulrunner stubs for windows to work fine. Let's uplift to m-b.
Attachment #8644695 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.