1060897 - Static-link the CRT into Instantbird executable (/im/app/moz.build). Port Bug 1023941 Part 1

Status: RESOLVED DUPLICATE of bug 1096086

(Instantbird Graveyard :: Other, defect)

Description

[Ian Neal]

(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

Comment 1

[Ian Neal]

Attachment: Port changes to app/moz.build

The patches from bug 882968 and bug 1055867 would need to be applied before applying this one.

Comment 2

[Florian Quèze [:florian]]

Comment on attachment 8481904 [details] [diff] [review]
Port changes to app/moz.build

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

rs=me. Thanks! :)

Comment 3

[(Away)]

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.

Comment 4

[Ian Neal]

florian, which route do you want to take?

Comment 5

[Florian Quèze [:florian]]

(In reply to David Major [:dmajor] from comment #3)
> Your main .exe makes calls to jemalloc

I don't see where it does that.

Comment 6

[(Away)]

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.

Comment 7

[(Away)]

Oh - I was looking at 1.5 from the website. The latest nightly 1.6 looks fine.

Comment 8

[(Away)]

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.

Comment 9

[Florian Quèze [:florian]]

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.

Comment 10

[(Away)]

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.

Comment 11

[Florian Quèze [:florian]]

Oh OK, now that I've looked at the patch again that makes more sense. I guess I was confusing mozglue and xpcomglue.

Comment 12

[aleth [:aleth]]

I didn't see this bug when I did bug 1096086 :-(

Is there anything in this discussion we still need to take care of?

Comment 13

[Florian Quèze [:florian]]

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