Nick Thomas [:nthomas] (UTC+12) Assignee
	Description • 9 years ago

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.

	Mike Hommey [:glandium]
	Comment 1 • 9 years ago

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

	Benjamin Smedberg
	Comment 2 • 9 years ago

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.

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 3 • 9 years ago

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.

	Benjamin Smedberg
	Comment 4 • 9 years ago

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.

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 5 • 9 years ago

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.

	bhearsum@mozilla.com (:bhearsum)
	Comment 6 • 9 years ago

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

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 7 • 9 years ago

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 ?

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 8 • 9 years ago

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

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 9 • 9 years ago

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

	Mike Hommey [:glandium]
	Comment 10 • 9 years ago

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

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 11 • 9 years ago

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)

	Mike Hommey [:glandium]
	Comment 12 • 9 years ago

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.

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 13 • 9 years ago

With comment, carrying review.

	Pulsebot
	Comment 14 • 9 years ago

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

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 15 • 9 years ago

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

	Carsten Book [:Tomcat]
	Comment 16 • 9 years ago

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

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 17 • 9 years ago

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.

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 18 • 9 years ago

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.

	Nick Thomas [:nthomas] (UTC+12) Assignee
	Comment 19 • 9 years ago

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