1174011 - xulrunner-stub builds broken on windows since June 5th

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 1

[Mike Hommey [:glandium]]

(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?

Comment 2

[Benjamin Smedberg]

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.

Comment 3

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 6

[[e-mail] (: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.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

glandium, do you have any thoughts about my (naive) guess in comment #7 ?

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

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'.

Comment 10

[Mike Hommey [:glandium]]

Yeah, seems like adding USE_LIBS += ['mfbt_staticruntime'] on windows would "fix" it.

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Add mfbt_staticruntime

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)

Comment 12

[Mike Hommey [:glandium]]

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.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Add mfbt_staticruntime (with comment)

With comment, carrying review.

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2ac09126d207

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/2ac09126d207

Comment 17

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 18

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 19

[Nick Thomas [:nthomas] (UTC+12)]

https://hg.mozilla.org/releases/mozilla-beta/rev/f4393cc8642d