(from Bug 1023941 comment #0) > In order to be able to support Windows XP SP2 with Visual C++ 2013, we need > to link statically to the CRT in firefox.exe and mozglue.dll but dynamically > to everything else. > > Is this something that the build system already supports? If not, can you > please give us a rough estimate on how much work that's going to be and how > it would work? > > Thanks! Looks like we need to port: Part 1: Static-link the CRT into firefox.exe. https://hg.mozilla.org/mozilla-central/rev/baa3f852133b
The patches from bug 882968 and bug 1055867 would need to be applied before applying this one.
Attachment #8481904 - Flags: review?(florian)
Summary: Static-link the CRT into Instantbird executable (/suite/app/moz.build). Port Bug 1023941 Part 1 → Static-link the CRT into Instantbird executable (/im/app/moz.build). Port Bug 1023941 Part 1
Comment on attachment 8481904 [details] [diff] [review] Port changes to app/moz.build Review of attachment 8481904 [details] [diff] [review]: ----------------------------------------------------------------- rs=me. Thanks! :)
Attachment #8481904 - Flags: review?(florian) → review+
Unfortunately, porting Part 1 isn't sufficient to fix XPSP2. Details are in bug 1023941 comment 32. Your main .exe makes calls to jemalloc, which will interfere with the SP2 hacks. You would either need to move those malloc calls out of the main exe, or stop using jemalloc. On the other hand, this only matters if you plan to switch to VS2013 and still support XPSP2. If you decide that you don't care, you can #define XRE_DONT_SUPPORT_XPSP2 before you #include "nsWindowsWMain.cpp" in order to silence the asserts.
florian, which route do you want to take?
(In reply to David Major [:dmajor] from comment #3) > Your main .exe makes calls to jemalloc I don't see where it does that.
Depends.exe shows a dependency from instantbird.exe to moz_xmalloc and moz_free in mozalloc.dll. I'm not sure what's causing it. The -verbose flag on the linker can offer some clues.
Oh - I was looking at 1.5 from the website. The latest nightly 1.6 looks fine.
Also in that nightly I don't see any use of mozglue.dll, so you probably don't need to mention mozglue at all in moz.build. It might give you linker warnings about unused delayloads.
Thanks for checking! Here is the build log of the latest Windows nightly: http://buildbot.instantbird.org/builders/win32-nightly-default/builds/1505/steps/compile/logs/stdio I don't see any linker warning near the creation of instantbird.exe, but maybe I'm not looking for the right thing.
The current nightlies don't link mozglue, but the patch in this bug proposes to add: DELAYLOAD_DLLS += [ 'mozglue.dll', ] and USE_LIBS += [ 'mozglue', ...which are probably unnecessary.
Oh OK, now that I've looked at the patch again that makes more sense. I guess I was confusing mozglue and xpcomglue.
I didn't see this bug when I did bug 1096086 :-( Is there anything in this discussion we still need to take care of?
(In reply to aleth [:aleth] from comment #12) > I didn't see this bug when I did bug 1096086 :-( > > Is there anything in this discussion we still need to take care of? I guess no. Sorry for not spotting the duplicated effort :-/.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1096086
You need to log in before you can comment on or make changes to this bug.